✍️ 필사 모드: フロントエンドテスト 2025 — Vitest·Jest·Bun·Testing Library·Playwright·Storybook·MSW·ビジュアル回帰·AI (シーズン6 第11回)

プロローグ — なぜテストスタックが楽になったか

2024–2025に3つのことが変わってフロントエンドテストが簡素化された。

1. Vitestが成熟し、Jestユーザーの多くを吸収。速度 + ESMネイティブ + Vite統合の複利。
2. Playwrightが退屈 (良い意味で) に — 動く、クロスブラウザ、CI、良ツール。
3. AI生成テストがギミックから「まともな初稿」へ — Cursor、Continue、Claude Codeがまともなテストを書ける。

本稿は2026年に何を実際に書くか、どの比率で。

1章. テストピラミッドは今も正しい

1:10:100のピラミッド (e2e : 統合 : ユニット) は今も正しい形。変わったもの:

• ユニット層は今まで以上に安い (Vitestは即時)。
• 統合層が豊かに (Testing Library + MSW + Storybook)。
• e2e層が信頼できるように (Playwrightが大規模でCypressを置換)。

アンチパターン: 逆ピラミッド (多くのe2e、少ないユニット) — 脆弱、遅い、高価。

2章. ユニットテスト — Vitestが答え

Vitestが勝った理由

• ESM先行、TS標準。
• Viteと同じconfig — モノレポ至福。
• Happy-domとJSDOM両対応。
• 即時watchモード。
• Vitest UI (ブラウザダッシュボード)。

最小セットアップ

// vitest.config.ts
import { defineConfig } from 'vitest/config'
import react from '@vitejs/plugin-react'
export default defineConfig({
  plugins: [react()],
  test: {
    globals: true,
    environment: 'happy-dom',
    setupFiles: ['./test/setup.ts'],
  },
})

Jestで今もOKな時

• 巨大なレガシーJestスイート (移行コスト > 利益)。
• React Native (Jestは今も標準)。

Bun test

• 生ベンチ最速ランタイム。
• 純Bunスタック向き。
• Vitestより生態系小。

3章. コンポーネントテスト — Testing Library + Storybook 8

Testing Library

• 「ユーザーが見るものをテスト、コンポーネントがレンダーするものでなく」。
• getByRole, getByLabelText, userEvent。
• VitestまたはJestで動作。

Storybook 8 (2024リリース) + Test Runner

• 各ストーリーがテストになる。
• play関数でインタラクション + アサーションをスクリプト。
• ポータブルストーリー: ストーリーをVitestにインポートし通常テストとして実行。
• Chromaticがビジュアル回帰と統合。

パターン: ストーリーを先に書く、ストーリーをテストする。1ファイル3用途: ドキュメント、ユニットテスト、ビジュアル回帰。

4章. 統合テスト — MSWが糊

Mock Service Worker (MSW) がfetch呼び出しをネットワーク層で傍受。同じモックが動く:

• ユニットテスト (Vitest/Jest)。
• Storybook。
• Cypress/Playwright。
• 開発サーバ。

// mocks/handlers.ts
import { http, HttpResponse } from 'msw'
export const handlers = [
  http.get('/api/users', () => HttpResponse.json([{ id: 1, name: 'Alice' }])),
]

利点: テストフィクスチャ = 開発フィクスチャ = ドキュメントフィクスチャ。単一の真実源。

5章. E2E — Playwrightがデフォルト

Playwrightの理由

• クロスブラウザ (Chromium、Firefox、WebKit)。
• 自動待機内蔵 — flakyテスト減。
• トレースビューア、タイムトラベルデバッグ、ネットワーク検査。
• VSCode拡張、CIキャッシング、シャーディング。

Playwrightプラクティス

• Page Object Model、軽く — 過剰なPOMは可読性を損ねる。
• テスト隔離 — 各テストが新しいブラウザコンテキスト。
• アクセシビリティスナップショット axe-playwrightまたは内蔵a11y。
• 失敗時のみトレース — 毎ラントレースは高価。

Cypress

• DX で今も愛されるが市場シェア減。
• 既に投資済みなら検討価値。

Bunネイティブe2e

• 出現中だが2026年時点でPlaywright置換ではない。

6章. ビジュアル回帰 — Chromatic, Percy, Loki

• Chromatic (Storybookチーム製) — ストーリー単位スクリーンショット、Storybookと連携。
• Percy (BrowserStack) — 広く、多フレームワーク対応。
• Loki / Reg-cli — セルフホストオプション。

パターン: 各PRでビジュアル回帰がStorybookプレビューで実行。ボットコメントで視覚diff。

注意: 誤検知が多すぎる (小さなAA diff) → チームが無視 → 信号喪失。しきい値を早めに調整。

7章. A11yテスト — 各層に内蔵

• axe-core + @axe-core/playwright — ユニット、コンポーネント、e2e層で。
• Storybook a11yアドオン — 各ストーリーでaxe実行。
• Lighthouse CI — プレビューデプロイで実行。

目標: アクセシビリティ失敗がビルド失敗に、「誰かの仕事」ではなく。

8章. 契約テスト — Zod + 型付きAPI

tRPC/GraphQL/OpenAPIでは契約テストがほぼ自動。RESTでは:

• Zodスキーマをクライアント·サーバ両方で、OpenAPIから生成。
• Pact (コンシューマ駆動契約テスト) バックエンドが独立出荷の時。
• Prism by Stoplight OpenAPIモック用。

9章. パフォーマンステスト

• Lighthouse CI — PR単位、回帰時ビルド失敗。
• WebPageTest API — より豊かなシナリオ。
• k6 (Grafana) — 負荷テスト、ブラウザスクリプトシナリオ付き。
• Chrome DevTools Performanceトレース — ローカルプロファイリング。

パフォーマンス予算をCIに結びつけてLCP回帰を出荷しない。

10章. AI拡張テスト

2026年に動く:

• コンポーネントソースからのテストスキャフォールド生成 — Cursor/Claude Codeがうまく。
• 失敗テストの修正提案 (Datadog FlakyTest、Trunk Merge Queue)。
• 記録されたブラウザセッションからのPlaywrightテスト生成 (npx playwright codegen)。
• AI支援コードカバレッジ分析 (テストが必要な分岐を提案)。

まだ動かない:

• 「このアプリの完全なテストスイートを書いて」 — 浅すぎ、幻覚アサーション多い。
• 人間レビューなしの自動テスト修復 — 微妙にドリフト。

ルール: AIが初稿、人間がレビュー·引き締め。

11章. Flakiness — 敵

Flakyテストがチームの信頼を破壊。修正:

• デフォルト自動待機 (Playwrightがこれを行う)。
• テストでsetTimeoutなし — 時計でなく条件待ち。
• ネットワーク隔離、MSW使用、ユニット/統合で実APIを叩かない。
• Flakyテストをslow laneに隔離、所有者タグ付きで、無制限リトライでなく。
• 時間固定: 日付依存テストに vi.useFakeTimers() または faketime。

鍵メトリクス: flake rate < 1%。これ超でチームがCI失敗を無視する。

12章. カバレッジ — ツール、目標でなく

• 80%ラインカバレッジで十分な下限。100%は追わない。
• ミューテーションテスト (Stryker) が「通るが確認しない」テストを暴く — カバレッジ単独より有用。
• カバレッジはクリティカルパスに集中: 決済、認証、支払い。

13章. 2026年理想スタック

12項目チェックリスト

1. ユニットテストがPRで10秒未満？
2. E2Eがシャーディング付きで3分未満？
3. Flake rate が 1%未満？
4. 各コンポーネントにStorybookストーリー？
5. PRごとにビジュアル回帰？
6. A11y失敗がビルド失敗？
7. 全ネットワークモックにMSW？
8. 契約テストが生成 (手書きでなく)？
9. CIにパフォーマンス予算？
10. ディレクトリごとカバレッジしきい値？
11. テストランナーがIDE (VSCode/WebStorm) と統合？
12. AIペアプログラミングワークフローにテスト執筆含まれる？

10アンチパターン

1. 実装詳細のテスト (CSSクラスをチェック)。
2. e2eが多すぎ — ピラミッド逆転。
3. テストでsetTimeout。
4. ユニットテストで実API呼び出し。
5. ビジュアル回帰でゼロ許容 — 微細ピクセル変更でトリガ。
6. 目標としての100%カバレッジ — 無用なテストを生む。
7. テスト間の共有可変状態。
8. 大きなbeforeAllセットアップ — テスト順序依存。
9. レビューなしスナップショット — グリーンパスが真の回帰を隠す。
10. 「3回リトライで修正」したflakyテスト — 根本原因を隠す。

次回予告

シーズン6 第12回: フロントエンドCI/CD·デプロイ 2025 — GitHub Actions、Turborepo Remote Cache、Vercel、Netlify、Cloudflare、プレビュー環境、カナリア、機能フラグ、SLSA/SBOM。

— フロントエンドテスト編、完。