End-to-End — ユーザーが実際にアプリを操作する流れをそのまま再現し、システム全体が正しく動くかを検証するテスト。
概要
E2E テストは ブラウザやモバイルアプリを自動操作 し、UI からデータベース・外部 API までを通したシナリオを検証する。 ユーザー視点での「動く」 を保証する最も上位のテスト。
| 観点 | E2E テストの特徴 |
|---|---|
| 対象 | アプリケーション全体（UI + バックエンド + DB + 外部 API） |
| 速度 | 数秒〜数十秒 / 1 件 |
| 件数の目安 | 数十（ハッピーパス中心） |
| 外部依存 | 本番に近い環境を構築 |
| 主な検証 | ユーザーシナリオ / クリティカルパス |
代表的なツール
| ツール | 特徴 |
|---|---|
| Playwright | Microsoft 製、複数ブラウザ対応、最新世代の定番 |
| Cypress | DX に優れた E2E フレームワーク、デバッグ画面が強い |
| Selenium / WebDriver | 古典、複数言語対応 |
| Puppeteer | Chrome/Chromium 専用、ヘッドレス操作 |
「ハッピーパスのみ網羅」が定石
E2E は実行コストが高い。 すべてのケースを E2E で検証しようとすると CI が破綻 する。エッジケースは下位レベル（結合テスト・単体テスト）に任せ、E2E は 「業務上の主要シナリオが動く」ことだけを担保 する。
| カバーすべき | カバーしなくてよい |
|---|---|
| 主要業務フロー（注文・決済・ログイン） | バリデーションのエラー表示 |
| 重要画面の表示 | 細かい入力パターン |
| 課金・通知などお金が絡む処理 | 内部ロジックの分岐網羅 |
AI 駆動開発との関係
E2E テストは AI に任せにくい レイヤー：
| 課題 | 理由 |
|---|---|
| UI 変更で頻繁に壊れる | セレクタが変わる、レイアウトが変わる |
| デバッグが難しい | 失敗してもスクリーンショットを見ないと原因不明 |
| 実行が遅い | AI ループの速度を落とす |
人間が骨組みとセレクタ戦略を決めて、AI には個別シナリオの実装を任せる のが現実解。data-testid などの安定セレクタを徹底すると AI 生成コードの保守性が上がる。
関連記事
- 開発手法ガイド：テスト技法編 — E2E の位置づけと節度
- 開発手法ガイド：アトミックデザイン編 — Storybook と組み合わせた段階テスト