テストの追加・補強・再生成

モード判定

以下の優先順で判定する：

1. implement-spec から呼ばれた場合 → TDDモード（テスト設計書からテストコードを先行生成。実装コードはまだない）
2. 「追加して」「補強して」「足りない」 → 補強モード（既存テストを残して不足分を追加）
3. 「作り直して」「リセットして」「全部書き直して」 → 再生成モード（既存テストを削除して一から作成）

再生成モードの場合：

1. 対象のテストファイルを一覧表示してユーザーに確認する

   以下のテストファイルを削除して作り直します：
   - tests/auth.test.ts
   - e2e/auth.spec.ts
   よろしいですか？
   

2. 確認後、既存テストファイルを削除してから生成に進む

テンプレート参照

以下のテンプレートを参照し、テスト仕様書の生成時にセクション構成を合わせる：

テンプレート	用途
docs/templates/phase4/unit-test-spec.md	単体テスト仕様書の構成
docs/templates/phase4/integration-test-spec.md	結合テスト仕様書の構成

テンプレートが存在しない場合は、テスト仕様書の生成をスキップしてテストコードのみ生成する。

TDDモード（implement-spec から呼ばれた場合）

テスト設計書（docs/design/test-design.md）が存在し、かつ実装コードがまだない場合に動作する。 テストを先に書き、全てREDの状態（テスト失敗）でコミットする。 implement-spec の coder がこのテストを GREEN にするコードを書く。

TDDモードの手順

1. docs/design/test-design.md の対象REQ-IDのテストケース一覧を読む
2. CLAUDE.md のテスト設定を確認（フレームワーク、認証バイパス等）
3. テストケース一覧に基づいてテストコードを生成する：
   • ユニットテスト: テスト設計書の「ユニットテスト」テーブルの各行を1つのテストケースに変換
   • E2Eテスト: テスト設計書の「E2Eテスト」テーブルの各行を1つのシナリオに変換
   • 横断テスト: 認証・状態遷移・エラーハンドリングのテストも生成
4. テストコードの実装はスタブ/モックで最低限コンパイルが通る状態にする：
   • import先のモジュールがまだ存在しない → モックファイル or jest.mock() でスタブ化
   • APIエンドポイントがまだ存在しない → E2Eテストは test.skip() でマークしておく（実装後に有効化）
5. spec-map.yml に tests エントリを追加
6. コミット: test: [REQ-ID] テストコードを先行生成（RED状態）

TDDモードのルール

• テストケースの追加・削除はしない。 テスト設計書のケースを忠実にコード化する
• テストが全てREDであることは正常。GREEN にするのは implement-spec の coder の仕事
• E2Eテストで実装コードが必要な箇所は test.skip() にする（実行時エラーを回避）
• テスト設計書に「※ 仮名」と注記されたモジュール名は、アーキテクチャから推定してインポートパスを決める

---

事前確認（補強モード・再生成モード共通）

1. CLAUDE.mdの「テスト設定」セクションを読む
   • テストフレームワーク、devサーバーURL、認証の扱いを確認
   • 「テスト設定」が未記入の場合：コードリポのpackage.json等を調査して自動でCLAUDE.mdに記入する
2. テストフレームワークがインストール済みか確認
   • 未インストールの場合：インストールコマンドを提示して人間に確認を求める
   • Playwrightの場合：npx playwright install でブラウザもインストール済みか確認

ユニットテスト生成

3. 2段階探索 でテスト対象の実装ファイルを特定
4. 既存テストを確認し、カバレッジが不足している箇所を特定
5. ユニットテストを生成：
   • 正常系：主要な入出力パターン
   • 異常系：バリデーションエラー、未認証、権限不足、存在しないリソース
   • 境界値：上限・下限・空配列・null
6. spec-map.yml 操作ガイド に従い、tests セクションにエントリを追加
7. テストを実行して全てパスすることを確認

E2Eテスト生成

CLAUDE.md の test_e2e を確認し、E2Eフレームワークに応じたテストを生成する。 test_e2e: none の場合はこのセクション全体をスキップする。 技術スタック対応ガイド のE2Eテストフレームワーク別対応表を参照。

8. 要件定義書の受入条件を読む → 受入条件ごとにテストシナリオを作成
9. 認証の扱いを決める：
   • CLAUDE.mdの「テスト設定」を確認
   • 外部OAuth（X, Google, GitHub等）はE2Eテストで直接テストしない（CAPTCHA・2FA・レート制限で動かない）
   • 代わりにテスト用の認証バイパスを実装する： a. テスト環境のときだけ有効なテスト用ログインエンドポイントを作る b. テスト用ユーザーのセッションを直接発行する c. E2Eテストはこのエンドポイントでログインしてから、ログイン後の機能をテストする
   • テスト用エンドポイントが未実装の場合：実装を提案して人間に確認を求める
   • OAuthフロー自体（リダイレクト→コールバック）は手動確認に任せる
10. 外部APIの扱いを決める：
    • 外部API（X API, Stripe, OpenAI等）はE2Eテストで実際に叩かない（レート制限・テストデータ不安定・API障害でテストが壊れる）
    • バックエンドにモックモードを実装する： a. テスト環境のとき、外部APIを呼ぶ関数が固定のJSONを返すようにする b. 固定データはテスト対象の画面表示に必要な最低限のフィールドを含める c. 正常系・エラー系（API障害、空データ）の両方のモックを用意する
    • モックモードが未実装の場合：実装を提案して人間に確認を求める
    • E2Eテストは「モックデータが画面に正しく表示されるか」を検証する
11. E2Eテストを生成：
    • devサーバーURLはCLAUDE.mdの「テスト設定」から参照
    • ページオブジェクトパターンを使用（テスト対象のページごとにクラスを作る）
    • 各テストは独立して実行可能にする（他のテストに依存しない）
    • 待機はフレームワークの推奨API（例: Playwright=waitForSelector/waitForResponse, Cypress=cy.wait/cy.intercept）を使う。固定sleepは使わない
    • 認証が必要なテストはセットアップフックでテスト用ログインを実行
12. E2Eテストを実行して全てパスすることを確認
    • devサーバーが起動していない場合：起動コマンドを実行してから（CLAUDE.mdの開発コマンド参照）テストを実行

テスト仕様書の生成

13. テンプレートが存在する場合、テストコードと併せてテスト仕様書も生成する：
    • 単体テスト仕様書 (docs/tests/unit-test-spec.md):
      • テンプレート（docs/templates/phase4/unit-test-spec.md）のセクション構成に従う
      • 生成したユニットテストのテストケース一覧を記載
      • テスト対象モジュール、カバレッジ目標、テストデータを整理
      • 既にファイルが存在する場合は、該当モジュール分を追記・更新
    • 結合テスト仕様書 (docs/tests/integration-test-spec.md):
      • テンプレート（docs/templates/phase4/integration-test-spec.md）のセクション構成に従う
      • 生成したE2Eテストのシナリオ一覧を記載
      • API結合テスト、画面遷移テストを整理
      • 既にファイルが存在する場合は、該当機能分を追記・更新 → コミット: docs: テスト仕様書を追加/更新

仕上げ

14. .claude/skills/_shared/finish-impl.md の共通仕上げ手順を実行
15. 次のステップを提案（「他の機能のテストも追加しますか？」「システムテスト・UAT仕様書も作りますか？」）
    • 再生成モードの場合：manual-test-cases.xlsx の該当Spec IDの行も再生成する

ルール

• 既存コードのロジックは変更しない（テスト追加のみ）
• テストファイルは必ず spec-map.yml に登録すること
• docs/impact-reports/ があればテスト観点を参照する
• E2Eテストのファイル名は tech-stack-guide.md のE2E対応表に従う（例: Playwright=[機能名].spec.ts, Cypress=[機能名].cy.ts）