ブログ記事
E2Eテストばかりで CIが遅くなっている人へ──『フロントエンド開発のためのテスト入門』のテスト戦略
画面を変えるたびに E2E テストが壊れ、修正するコストがかかる。テストが役に立つどころか開発の邪魔になっている——そういう状況は、テストの種類と配分の設計に問題がある。
吉井健文著『フロントエンド開発のためのテスト入門 今からでも知っておきたい自動テスト戦略の必須知識』（翔泳社、2023年）は、個々のテストの書き方の前に「どのテストをどの割合で書くか」という戦略から始める。Next.js のアプリ開発を通じて、単体テスト・UI コンポーネントテスト・ビジュアルリグレッションテスト・E2E テストを一通り扱う。
1. E2E 偏重の「アイスクリームコーン型」を避ける
多くのプロジェクトで E2E テストが大量に書かれる。ブラウザ操作を記録するだけで作れるため手軽だが、実行が遅く、ちょっとした UI 変更で壊れやすい。テストの大半が E2E という状態を「アイスクリームコーン型」と呼び、本書はこれを避けるべきアンチパターンとして位置づける。
本書が提案するのは「テスティングトロフィー」の考え方だ。実行速度が速く安定している単体テストと結合テストを土台に多く書き、E2E は重要なユーザーフローのみに絞り込む。E2E の数を増やすほど保護の粒度が上がるわけではなく、むしろ CI の安定性とメンテナンスコストが悪化する。テストレベルごとの役割を把握して配分を変える——それだけで状況はかなり変わる。
flowchart TD
subgraph TROPHY["✅ テスティングトロフィー（推奨）"]
E["E2E テスト\n重要フローのみ（少ない）"]
I["結合テスト（多め）"]
U["単体テスト（多い）"]
S["静的解析（基盤）"]
S --> U --> I --> E
end
subgraph CONE["❌ アイスクリームコーン型（アンチパターン）"]
E2["E2E テスト（大量）"]
I2["結合テスト（少ない）"]
U2["単体テスト（ほぼなし）"]
U2 --> I2 --> E2
end
style TROPHY fill:#e8f8e8,stroke:#4caf50
style CONE fill:#fce8e8,stroke:#e53935
2. Testing Library の「暗黙のロール」でアクセシビリティとテストを同時に改善する
UI コンポーネントのテストで要素を取得するとき、data-testid のようなテスト専用の識別子を使うのは避けた方がよい。本書は getByRole を使って要素を取得する方法を中心に据える。
getByRole はスクリーンリーダーなどの支援技術が HTML をどう解釈するかという「暗黙のロール」に基づいて要素を特定する。例えばボタン要素なら role="button" が暗黙的に付いているため、getByRole('button', { name: '送信' }) でアクセシブルな名前と組み合わせて取得できる。
この方法でテストを書いていると、テストが通らない＝アクセシビリティが壊れているというシグナルになる。テストとアクセシビリティが連動する仕組みで、正直これは気づいたときに少し感心した。
3. モックはシンプルに、テストに複雑なロジックを入れない
外部 API や現在時刻への依存をモックで置き換えることは必要だが、モックを多用しすぎると実際の動きと乖離したテストになる。本書はスタブ・スパイ・フェイクなどテストダブルの種類を整理し、それぞれを使う状況を明確にする。
テストコード自体についても、共通化のためにユーティリティ関数を複雑に作り込むことは避けるべきとされる。テストケース内に複雑なロジックを入れず、冗長でも「準備・実行・検証」が 1 ケースで完結するシンプルな構造を保つことが、長期的なメンテナンス性を左右する。
Storybook を使ったコンポーネントエクスプローラーによるビジュアル確認と、Playwright を使った E2E テストも後半の章で扱われる。
4. この本が効く場面
「テストを書いた方がいいのは分かっているが、単体・結合・E2E のどれを、どのツールで、どこから書き始めればいいか決められない」——本書がまず効くのはこの停滞だ。関数の単体テストから始まり、モック、UI コンポーネントテスト、Storybook 連携へと徐々に難易度が上がる学習ステップが用意されているので、着手の順番を自分で設計しなくても手が動き出す。
もう一つは、E2E 偏重からの立て直しだ。文言修正やデザイン変更のたびに CI が赤くなり、テストの修繕が日課になっているチームには、本書の「再配置」の考え方が道筋になる。画面の見た目はビジュアルリグレッションテストで、フォームなど機能のバリデーションは結合テストで検証し、E2E には重要なユーザーフローだけを残す。テストを減らすのではなく置き場所を変えることで、保護を弱めずに運用コストを下げる方向へ進める。
5. 向いている人・向いていない人
向いている人：
- React や Next.js で UI 構築や API 連携は実装できるが、自動テストコードを本格的に書いた経験がない
- プロジェクトの E2E テストが肥大化し、flaky な失敗の調査と修正にチームの時間が奪われている
- 開発チームが書く自動テストの中身を把握し、どこまでを自動に任せてどこを手動で検証するかの役割分担を設計したい QA エンジニア
向いていない人：
- フレームワークでの UI 構築経験がまだない人。本書は React・Next.js での開発経験を前提に進むため、先に『Reactハンズオンラーニング 第2版』のような実装の基礎を固めてからの方が吸収がいい
- Jest や Testing Library の API を網羅したリファレンスを探している人。本書の軸は戦略と使い分けにあり、細かい記法を都度引く辞書としては機能しにくいという読者の指摘がある
6. 読み方ガイド——判断基準は最初の 2 章で掴む
全 10 章のうち、テスト配分の判断基準にあたる戦略の話は第 1 章「テストの目的と障壁」と第 2 章「テスト手法とテスト戦略」にまとまっている。時間がなければ、まずこの 2 章で本書の背骨を掴むといい。第 3 章以降は、ログイン・記事の執筆・Like 機能を備えた Next.js 製の技術ブログサービスを一貫した題材に、単体テスト→モック→UI コンポーネントテスト→結合テスト→Storybook→ビジュアルリグレッション→E2E と積み上げる実装パートで、手元でコードを動かしながら進める前提の構成だ。
一つ期待値の調整をしておくと、本書の「テスト戦略」はテストピラミッドやテスティングトロフィーといったテストモデルの選択と配分を指している。QA の業界用語にある「プロジェクト全体のテスト方針の策定」という大局的な意味を想定して開くと射程が違う、という QA エンジニアの指摘がある。
7. 読んだ後のステップ
次に読む本としては『Testing JavaScript Applications』（Lucas da Costa）が DevBookPath のマップ上の続きになる。本書でフロントエンドのテストの型と配分を押さえたら、モック・非同期・統合テストの実践を JavaScript アプリケーション全体に広げ、個々の技法をプロジェクト単位の運用へ引き上げる段階だ。
実務での最初の一歩は、手元のリポジトリのテストを種類別に数えて、単体・結合・E2E の比率を出してみること。E2E に偏った逆三角形になっていれば、それが本書の言うアイスクリームコーン型で、どのテストをどこへ移すかという再配置の検討が、そのまま本書の読みどころと重なる。
筆者の体験から
自社サービスの管理画面を任され、機能を追加するたびに他の画面への影響を目視で確認する日々を送っていた時期に本書を読んだ。E2Eを足せば守れると考えて数本追加したが、ちょっとしたレイアウト変更のたびに赤くなり、直す作業そのものが目的になりかけていた。テスティングトロフィーの考え方を知ってからは、壊れて困るレベルから逆算してテストを配置する発想に切り替わり、E2Eを減らしても壊れにくくなるという逆説を実感した。レビューでも「ここはE2Eで」ではなく「結合テストの範囲で」と粒度を分けて言えるようになった。引っかかったのは、QA担当者と話す際に「テスト戦略」という言葉が指す範囲が本書とは違い、噛み合わない場面があったことだ。管理画面の一覧行にあったクリック領域をgetByRoleで取得しようとして失敗し、正体はdivへonClickだけ付けた要素だったという経験もある。button要素とaria-labelに置き換えるとテストは通り、キーボード操作ができていなかった事実にも気づかされた。
DevBookPath のマップで確認する
この本の学習パス上の位置づけ・前後の読書順は、DevBookPath のグラフで辿れます。
本記事のリンクには Amazon アソシエイト等の広告が含まれる場合があります。リンク経由の購入で運営者に紹介料が支払われることがあります。
この記事を共有
この地図を共有