テスト自動生成パイプライン

コース構成

このコースで学ぶこと

1. 01

   なぜテストが薄くなるか

   「あとで書く」テストは永遠に書かれない。CI に組み込んで強制する仕組みが必要。

   新機能の実装にテストはセットになるべきですが、納期プレッシャーでテストが後回しになるのが現実。結果、「テストが薄い」モジュールが増え、リグレッションが頻発する負のループに。

   Claude Code でテスト自動生成 + カバレッジチェックを CI に組み込めば、毎 PR で『テスト不足』を可視化できます。

   • 新規ファイルへの自動テスト追加
   • 既存テストの薄いモジュール特定
   • 境界値・エラーケースの自動追加
   • Snapshot テストの明示的アサーション化
   Skill 設計：1 ファイル単位で生成
2. 02

   Skill 設計：1 ファイル単位で生成

   「全ファイル一気にテスト書け」は質が落ちる。1 ファイルずつ、focused に。

   markdown

   ---
   name: gen-tests
   description: |
     渡されたファイル 1 つに対するテストを生成する。
     既存テストがあれば不足分のみ追加。
   ---
   
   対象: $ARGUMENTS
   
   ## 手順
   1. 対象ファイルを読み、公開関数・クラスをリスト
   2. 既存テスト（同名 .test.ts）があれば内容確認、カバーされている関数を除外
   3. 残りの関数について、以下を生成:
      - happy path（典型ケース）
      - boundary（境界値）
      - error case（不正入力・例外）
   4. .test.ts に追記 or 新規作成
   5. テスト実行 → 失敗があれば最小修正

   なぜテストが薄くなるかHook で『新規ファイルに自動テスト』
3. 03

   Hook で『新規ファイルに自動テスト』

   PostToolUse で Write を検知して、新規ファイルなら自動的に gen-tests を起動。

   json

   {
     "hooks": {
       "PostToolUse": [
         {
           "matcher": "Write",
           "if": "file matches src/**/*.ts && not file matches **/*.test.ts",
           "command": "claude -p \"/gen-tests ${FILE}\""
         }
       ]
     }
   }

   Skill 設計：1 ファイル単位で生成カバレッジ底上げの月次プロジェクト
4. 04

   カバレッジ底上げの月次プロジェクト

   薄いモジュール TOP 5 を毎月 /goal で底上げ。

   text

   > 月次カバレッジ底上げ作業:
   
   1. `pnpm test --coverage` で現状のカバレッジを取得
   2. ファイル単位でカバレッジを並べる（覆われている行 %）
   3. 80% 未満のファイル TOP 5 を特定
   4. /goal で以下を実行:
      /goal TOP 5 のファイルのカバレッジを 80% 以上に。
      `pnpm test --coverage` で確認、全テスト緑のまま。
      or stop after 30 turns

   出力イメージカバレッジ底上げプロンプトの返答（冒頭）

   現状のカバレッジを取得しました。80% 未満の TOP 5:
   
   | ファイル | 行カバレッジ | 不足ケース |
   |----------|--------------|------------|
   | src/lib/○○.ts | 52% | 異常系・null 入力 |
   | src/api/○○.ts | 61% | 403 / 404 分岐 |
   | … | | |
   
   この 5 ファイルを対象に /goal を開始します。
   …（完了後: 全体 71% → 84%）

   Hook で『新規ファイルに自動テスト』CI 統合と運用注意
5. 05

   CI 統合と運用注意

   PR で『カバレッジ X% 以下なら fail』にすると効果が高い。ただし最初から厳しくしない。

   • 最初は『カバレッジ低下を警告』のみ（fail しない）
   • 2 ヶ月後、徐々に閾値を上げる（70% → 75% → 80%）
   • テストが書きにくいコードを発見したら、設計を見直す（DI / interface 化）
   • AI 生成テストは『assertion が雑』になりがち、人間レビューを必ず

   理解度チェック

   1. Q1.テスト自動生成を CI に組み込むとき、最初から厳格な閾値で fail させるのは何が問題？

      AAI が壊れるBテストが書きにくい設計の負債を一気に押し付けることになり、抵抗を生んで運用が頓挫するCAPI 料金が上がるDGit の履歴が壊れる

   2. Q2.AI が生成したテストをマージ前に人間がレビューするときの観点として最も重要なものは？

      Aテスト関数の命名規則B『何を保証しているか』が明確で、assert がモック自身の値ではなく実装の振る舞いを検証していることCコメントの絵文字Dテストファイルの拡張子

   3. Q3.テスト自動生成 Skill の入力として最も適切な組合せは？

      A対象ファイルの実装コードと、リポジトリのテスト規約（命名・配置・モック方針）を書いた CLAUDE.mdB経費精算 CSVCSlack のスレッド IDD未公開のクライアント原稿
   カバレッジ底上げの月次プロジェクト