E2Eテストばかりで CIが遅くなっている人へ──『フロントエンド開発のためのテスト入門』のテスト戦略

画面を変えるたびに E2E テストが壊れ、修正するコストがかかる。テストが役に立つどころか開発の邪魔になっている——そういう状況は、テストの種類と配分の設計に問題がある。

吉井健文著『フロントエンド開発のためのテスト入門 今からでも知っておきたい自動テスト戦略の必須知識』（翔泳社、2023年）は、テストの書き方だけでなく「どのテストをどの割合で書くか」という戦略から始める。Next.js のアプリ開発を通じて、単体テスト・UI コンポーネントテスト・ビジュアルリグレッションテスト・E2E テストを一通り扱う。

1. E2E 偏重の「アイスクリームコーン型」を避ける

多くのプロジェクトで E2E テストが大量に書かれる。ブラウザ操作を記録するだけで作れるため手軽だが、実行が遅く、ちょっとした UI 変更で壊れやすい。テストの大半が E2E という状態を「アイスクリームコーン型」と呼び、本書はこれを避けるべきアンチパターンとして位置づける。

本書が提案するのは「テスティングトロフィー」の考え方だ。実行速度が速く安定している単体テストと結合テストを土台に多く書き、E2E は重要なユーザーフローのみに絞り込む。E2E の数を増やすほど保護の粒度が上がるわけではなく、むしろ CI の安定性とメンテナンスコストが悪化する。テストレベルごとの役割を整理し、費用対効果を意識して配分することが前提になる。

2. Testing Library の「暗黙のロール」でアクセシビリティとテストを同時に改善する

UI コンポーネントのテストで要素を取得するとき、data-testid のようなテスト専用の識別子を使うのは避けた方がよい。本書は getByRole を使って要素を取得する方法を中心に据える。

getByRole はスクリーンリーダーなどの支援技術が HTML をどう解釈するかという「暗黙のロール」に基づいて要素を特定する。例えばボタン要素なら role="button" が暗黙的に付いているため、getByRole('button', { name: '送信' }) でアクセシブルな名前と組み合わせて取得できる。

この方法でテストを書いていると、テストが通らない場合に「アクセシビリティが損なわれているマークアップになっている」というシグナルとして機能する。テストを書く行為が、結果としてアクセシブルな UI の作成を促す構造だ。

3. モックはシンプルに、テストに複雑なロジックを入れない

外部 API や現在時刻への依存をモックで置き換えることは必要だが、モックを多用しすぎると実際の動きと乖離したテストになる。本書はスタブ・スパイ・フェイクなどテストダブルの種類を整理し、それぞれを使う状況を明確にする。

テストコード自体についても、共通化のためにユーティリティ関数を複雑に作り込むことは避けるべきとされる。テストケース内に複雑なロジックを入れず、冗長でも「準備・実行・検証」が 1 ケースで完結するシンプルな構造を保つことが、長期的なメンテナンス性を左右する。

Storybook を使ったコンポーネントエクスプローラーによるビジュアル確認と、Playwright を使った E2E テストも後半の章で扱われる。

DevBookPath のマップで確認する

この本の学習パス上の位置づけ・前後の読書順は、DevBookPath のグラフで辿れます。

フロントエンドの地図を見る

---

本記事のリンクには Amazon アソシエイト等の広告が含まれる場合があります。リンク経由の購入で運営者に紹介料が支払われることがあります。