過剰テスト中毒と エラーテスト欠乏症 UI テスト二大疾病の根治療法 in Offers 202503 

Profile 名前: 佐藤 昭文（あっきー） ID: akfm_sato 仕事: フロントエンドエキスパート 活動 執筆: e.g. Next.js の考え方 OSS: location-state 

今日のテーマ: UI テスト二大疾病 過剰テスト中毒 エラーテスト欠乏症 単体テストにおける2 つの陥りやすいアンチパターンと、その対処法について 

過剰テスト中毒 単体テスト初学者が最初に陥るアンチパターン 

過剰テスト中毒とは 過剰テスト: テストとしての価値が低いもの 過剰テスト中毒: 過剰テストによってメンテ工数が増えてしまっている状態 テストとしての価値が低いものを排除することが重要 書けるテストをともかく書いてると、後々苦しくなってくる 

過剰テストの例 ページコンポーネントの実装 function RootPage() { // ... return ( ); } export default HomePage; 

過剰テストの例 あまりに自明なテストはバグを拾う確率が低い 過剰テストと考えられるテストケース test(" ページタイトルに'Hello, World' が存在すること", () => { render(); expect( screen.getByRole("heading", { name: "Hello, World", }), ).toBeInTheDocument(); }); 

良いテストの例 form のsubmit 時処理のテストはバグを拾う確率が比較的高い ボタン押下時の挙動はアプリケーションにおいても重要性が高く、デグレする可能性も高い部類 test(" 問い合わせ完了後に完了画面へ遷移すること", () => { // ... await user.click( screen.getByRole("button", { name: " 問い合わせ", }), ); expect(apiReq).toHaveBeenCalledTimes(1); expect(apiReq).toHaveBeenLastCalledWith({ // ... }); expect( await screen.findByRole("heading", { name: " 問い合わせが完了しました", }), ).toBeInTheDocument(); }); 

過剰テストを判断する審美眼 退行に対する保護 リファクタリングへの耐性 迅速なフィードバック 保守のしやすさ 良い単体テストとは、以下の4 つの指標によって判断することが可能 

エラーテスト欠乏症 単体テスト初学者が見落としやすいテスト観点 

エラーテスト欠乏症 エラーテスト: 通信の失敗などに代表される、エラー時UI に関するテスト エラーテスト欠乏症: エラーテストが一切ないもしくは足りてない状態 ユーザーにとってエラー時の挙動は当たり前品質の観点で重要 多くの人が正常系のテストを書くが、異常系のテストは抜けがち 

エラーテストを含めたテスト観点 想定できるエラーを可能な限り網羅的にテストすることが重要 Todo アプリにおける更新画面のテスト観点例 

エラーテストの例 Todo アプリにおける更新画面のテスト実装例 describe("Todo 取得通信でエラー", () => { test(" ネットワークエラー時、エラーメッセージが表示されること", async () => { // Arrange const apiRequestCall = jest.fn(); server.use( http.get("/api/todos", (req, res, ctx) => { return apiRequestCall(HttpResponse.error()); }), ); // Act render(); // Assert expect(await screen.findByRole("alert")).toHaveTextContent( " 通信エラーが発生しました。通信環境をご確認の上、再度お試しください。", ); expect(apiRequestCall).toHaveBeenCalledTimes(1); }); }); 

まとめ UI テスト二大疾病の根治療法 

まとめ 過剰テスト中毒の対処: テストの価値を見極め、良いテストに絞って書くことを意識しましょう エラーテスト欠乏症の対処: エラーパターンを列挙して、網羅的にテストしましょう テスト初学者が陥りやすいアンチパターンを念頭に、良いテストを目指しましょう 

End