概要

“テストを書いたコードは壊れない”のではない。
“壊れても気づける構造”に変わる。それがテスト戦略の本質である。

JavaScriptの開発において、ユニットテスト・統合テスト・E2Eテストは単なる実装補助ではなく、設計上の意思決定ツールである。
本稿では、テスト階層を設計上のスコープとして捉え、それぞれの目的・設計・選定技術・分離戦略を体系的に解説する。

1. テストピラミッドの設計原則

       ┌────────────┐
       │   E2E      │ ← 仕様検証・ブラウザ操作
       ├────────────┤
       │ Integration│ ← ユニット同士の連携
       ├────────────┤
       │   Unit     │ ← 単機能ロジック検証
       └────────────┘

✅ 単体で速いユニットテストを基盤に
✅ 統合で接続ミス・依存関係を検証
✅ E2Eで“ユーザー目線の仕様”を検証

2. ユニットテストの設計

✅ 目的：1つの関数・モジュールの振る舞いの検証

// sum.js
export function sum(a, b) {
  return a + b;
}

// sum.test.js
import { sum } from './sum';

test('adds 1 + 2 to equal 3', () => {
  expect(sum(1, 2)).toBe(3);
});

✅ 外部依存を持たない（副作用ゼロ）
✅ 仕様が関数レベルで明確になる
✅ フレームワーク例：Jest, Vitest

3. 統合テストの設計

✅ 目的：複数ユニット間の相互作用の検証

// userService.js
export async function getUserInfo(api, id) {
  const res = await api.fetch(`/users/${id}`);
  return res.data;
}

// userService.test.js
const mockApi = { fetch: jest.fn().mockResolvedValue({ data: { name: 'Toto' } }) };

test('getUserInfo returns user name', async () => {
  const result = await getUserInfo(mockApi, 1);
  expect(result.name).toBe('Toto');
});

✅ HTTP・DBなどの抽象化インターフェースをモック
✅ ユニットでは見えない依存間の連携不整合を検出
✅ モック戦略が設計の粒度に直結

4. E2Eテストの設計

✅ 目的：ブラウザ上でのユーザー操作とUIの仕様検証

// 使用例（Playwright / Cypress）
test('ログイン後にプロフィール画面が表示される', async ({ page }) => {
  await page.goto('/login');
  await page.fill('#email', 'toto@example.com');
  await page.fill('#password', 'secret');
  await page.click('text=ログイン');
  await expect(page.locator('h1')).toHaveText('プロフィール');
});

✅ 実際のブラウザ + 本物のUI
✅ 自動UI回帰テストのコア
✅ 実行コストが高いため、重要機能に限定

5. カバレッジとテスト優先順位の判断軸

機能	変更頻度	重要度	優先すべきテスト
ロジック関数	高	中	ユニット
API通信	中	高	統合
認証周辺	低	高	統合 + E2E
UI表示部	高	中	スナップショット or E2E
設定画面	低	低	ユニット or 無し

→ ✅ テストを書くコスト vs 発生しうる障害コストでバランスを設計

6. テストと設計の相関性

関数が長すぎる → テストが書きにくい → 設計が悪い
副作用が多すぎる → テストが不安定 → 責務が混在している
依存が密結合 → モックが困難 → 分離設計が必要

→ ✅ “テストしにくい構造”は、“壊れやすい構造”の警告である

よくあるミスと対策

❌ カバレッジ100%を目指すが意味のないテストばかり

→ ✅ “重要な振る舞い”に焦点を当てた設計的テストを優先

❌ UIテストをすべてE2Eで行い、実行が遅くなる

→ ✅ E2Eは仕様の証明、UI部品はユニット+スナップショットでカバー

❌ 外部APIに直で依存し、テストが不安定

→ ✅ 抽象化されたAPI層をインジェクション可能な形で分離

結語

テストとは、「壊れたことを検出する仕組み」ではない。
それは、「壊れても影響を限定できる構造」を作る設計の一部である。

ユニットで責務を閉じ
統合で依存を検証し
E2Eで体験を担保する

信頼性は偶然では得られない。
それは意図して設計された“検証構造”によってのみ生まれる。