E2E テスト
ユーザーの操作をブラウザ上で再現し、システム全体の動作を検証するテスト手法
E2E テストとは
E2E テスト (End-to-End Test) は、ユーザーの操作をブラウザ上で再現し、フロントエンドからバックエンド、データベースまでシステム全体の動作を検証するテスト手法である。「ユーザーがログインして商品を購入できるか」のようなシナリオを自動化する。
テストピラミッド
テストピラミッドを図で示す。
/ E2E \ ← 少数、遅い、高コスト
/ 結合テスト \
/ 単体テスト \ ← 多数、速い、低コスト
| レベル | 速度 | 信頼性 | コスト | 数 |
|---|---|---|---|---|
| 単体テスト | 最速 | 低い (モック) | 低い | 多い |
| 結合テスト | 中程度 | 中程度 | 中程度 | 中程度 |
| E2E テスト | 遅い | 高い (実環境) | 高い | 少ない |
Playwright での E2E テスト
Playwright での E2E テストのコード例を示す。
import { test, expect } from '@playwright/test';
test('ユーザーがログインできる', async ({ page }) => {
await page.goto('/login');
await page.fill('[name="email"]', 'alice@example.com');
await page.fill('[name="password"]', 'password123');
await page.click('button[type="submit"]');
await expect(page).toHaveURL('/dashboard');
await expect(page.locator('h1')).toHaveText('Dashboard');
});
test('商品を検索して詳細を表示', async ({ page }) => {
await page.goto('/');
await page.fill('[name="search"]', 'TypeScript');
await page.click('button[aria-label="検索"]');
await expect(page.locator('[data-testid="product-card"]')).toHaveCount(3);
await page.click('[data-testid="product-card"] >> nth=0');
await expect(page.locator('h1')).toContainText('TypeScript');
});
ツール比較
Playwright は Chromium・Firefox・WebKit を公式にサポートし、自動待機と並列実行が特徴。Cypress は対話的なテストランナーによるデバッグ体験に強みがあり、Chrome 系 (Chrome / Edge / Electron) と Firefox、実験的に WebKit へ対応する。Puppeteer は Chrome DevTools Protocol を直接扱う低レベル API が中心で、Firefox も WebDriver BiDi 経由で操作できる (2026 年 8 月時点)。
ブラウザの網羅性と並列実行で選ぶなら Playwright、失敗時に時間を巻き戻して確認できるデバッグ体験を重視するなら Cypress、テストより先にブラウザ操作の自動化やパフォーマンス計測が目的なら Puppeteer が向く。
CI での実行
CI での実行の例を示す。
# GitHub Actions
- uses: actions/checkout@v4
- run: npm ci
- run: npx playwright install --with-deps
- run: npx playwright test
- uses: actions/upload-artifact@v4
if: failure()
with:
name: playwright-report
path: playwright-report/
E2E テストの書き方のコツ
ユーザーの行動シナリオを書き、実装の詳細をテストしない。data-testid で要素を特定し、CSS クラス名での特定は避ける。重要なフローだけ E2E にし、全てを E2E でカバーしようとしない。自動待機 (Playwright) を活用し、sleep でタイミングを合わせない。
フレイキーテスト (不安定なテスト)
E2E テストは環境依存で不安定になりやすい。タイミング問題には自動待機や waitFor を使う。テストデータの依存にはテストごとにデータをリセットする。ネットワーク遅延にはモックサーバーを使う。
さらに掘り下げるなら関連書籍が参考になる。
この記事は役に立ちましたか?
関連用語
関連する記事
テスト本ガイド - テスト設計を学べる技術書の選び方
テストの書き方からテスト戦略まで学べる技術書の選び方を紹介。テストピラミッド、TDD の正しい読み方、テストの ROI の考え方を解説します。
「動くコード」と「良いコード」の間にある本
コードが動くようになった後、次に何を学べばよいのか。「動くコード」を「良いコード」に変えるために必要な知識と、それを効率的に学べる本の選び方を解説します。
バグを生むのは知識不足ではなく想像力不足である
バグの多くは、コードを書いた時点で「こういうケースもありうる」と想像できなかったことが原因です。想像力を鍛える読書法と、エッジケースへの感度を高める方法を解説します。