概要

テストとは「書くもの」ではなく「設計を証明するもの」である。
それは単なるチェックリストではなく、設計が意図どおりであることを保証する、もう一つのインターフェースである。

本稿では、JavaScriptにおけるテストを「単なるツール」から「設計構造の一部」へと昇華させるために必要な戦略を解説する。

1. テスト三層構造の理解と責務分離

レイヤー	主な対象	特徴
Unit Test	関数 / クラス	高速、ピュア、責務明確
Integration	モジュール / サービス	実際の依存間の整合性検証
E2E Test	UI + サーバ	ユーザー視点での振る舞い保証

→ ✅ それぞれ何を守るためのテストかを明確に設計する

2. ユニットテスト：純粋な構造の保証

function add(a, b) {
  return a + b;
}

test('加算関数', () => {
  expect(add(1, 2)).toBe(3);
});

✅ 入力と出力のみで定義される関数は最小の保証対象
✅ 副作用なし・依存なしが前提

3. 結合テスト：依存間の接続保証

import { fetchUser } from './api';
import { renderUser } from './ui';

test('ユーザー情報の取得と表示', async () => {
  const user = await fetchUser();
  const ui = renderUser(user);
  expect(ui).toContain(user.name);
});

✅ 外部呼び出し（API / DBなど）はmock/stubで制御
✅ 依存先の“契約”を守るテスト → インターフェース保証

4. モック戦略：何を偽装し、何を残すか

jest.mock('./api', () => ({
  fetchUser: jest.fn().mockResolvedValue({ id: 1, name: 'Toto' }),
}));

✅ モックは副作用の排除 or テスト高速化のための構造
✅ モックが乱立するとテストの意味が失われる → 構造の一部として設計すべき

5. E2Eテスト：動作の保証ではなく、流れの保証

// e.g. with Playwright
test('ログインしてダッシュボードが表示される', async ({ page }) => {
  await page.goto('/login');
  await page.fill('#email', 'user@example.com');
  await page.fill('#password', 'securepassword');
  await page.click('button[type=submit]');
  await expect(page).toHaveURL('/dashboard');
});

✅ E2Eは振る舞いの確認 + 回帰テストの最後の砦
❌ 頻度は少なめでよい → 回帰用に絞って設計

6. テスト容易性を前提にした構造設計

関数は副作用と切り離して設計
グローバル依存を減らし、DI / hook / context などで外部注入
データ構造は関数引数で与える

function createUserStore(apiClient) {
  return {
    fetch: () => apiClient.get('/user'),
  };
}

→ ✅ モック可能な構造にすることでテストしやすさ = 設計品質となる

7. CI / カバレッジとの統合戦略

✅ 全てのテストをCI上で実行し、“守られている”構造を保つ
✅ カバレッジはあくまで補助指標 → 低くても「テストすべき場所」がカバーされているならOK
✅ 重要なのは**“設計の意図がテストで守られているか”**

設計判断フロー

① テストがUI中心に偏っていないか？ → ロジック単位の分離を検討

② モックが意味をなしているか？ → 副作用・契約・境界で切る

③ ロジックとDOMが分離されているか？ → ユニットとE2Eの分離設計へ

④ テストが壊れたとき“なぜ”かがわかるか？ → 名前 / 構造を明示的に

⑤ テスト対象が関数でなければテスト不能では？ → 設計見直し

よくあるミスと対策

❌ UIの見た目ばかりをsnapshotでテストし、内部ロジックが壊れても気づかない

→ ✅ テストの粒度をUI / ロジックに明示的に分離

❌ モックだらけでテストが意味を成していない

→ ✅ モックの対象を**「制御不能な外部」だけに限定**

❌ E2Eで全てを保証しようとして時間がかかりすぎる

→ ✅ E2Eはユーザーフロー + 致命的回帰の監視用に絞る

結語

テストとは「安心を得るため」ではない。
それは**“設計を守るための防波堤”**であり、
未来の開発者への契約文書でもある。

責務単位で分離し
モックは構造的に設計し
振る舞いではなく“意図”を検証する

JavaScriptにおけるテスト設計とは、
“壊れても壊れた理由が分かり、すぐに直せる構造”をつくる戦略である。