| name | backend-test-gap-finder |
| description | 既存コードに対してテストが不足している箇所を体系的に洗い出し、優先度付きリストにする。コード複雑度・変更頻度・障害リスクを軸に評価する。「テスト不足どこ？」「テストギャップ調べて」「カバレッジ穴探して」などで起動。 |
Test Gap Finder
既存コードのテスト不足箇所を特定し、どこから埋めるべきか を優先度付きで提示する。
いつ使うか
- 新メンバーが品質状況を把握したい
- リリース前にリスクの高いテスト不足を潰したい
- レガシーコードベースに手を入れる前に防御壁を張りたい
実行手順
1. 対象範囲の決定
ユーザーに確認:
- リポジトリ全体 / 特定ディレクトリ / 特定モジュール
- どの層（unit / integration / e2e）を対象とするか
- 既知のホットスポット（最近バグが出た、最近大きな変更が入った）
2. カバレッジ情報の取得（ある場合）
- カバレッジ計測ツールがプロジェクトにあれば実行
- 無ければ、ファイル単位の対応関係から推測する
<impl>.go → <impl>_test.go が存在するか
src/foo.ts → src/foo.test.ts / __tests__/foo.test.ts が存在するか
ファイルの存在だけでは不十分（テストがあっても中身が薄いことも）。可能なら中身を一瞥する。
3. リスク評価軸
各ファイル / 関数について以下を評価:
| 軸 | 評価方法 |
|---|
| 複雑度 | 分岐・ループ・ネストの多さ、LOC |
| 変更頻度 | git log --oneline -- <path> の頻度 |
| 依存の広さ | 呼び出し元の数（Grep で参照検索） |
| 境界性 | 外部 I/O（DB、API、ファイル、時刻）を跨ぐか |
| 歴史的障害 | コミットメッセージに fix, bug, hotfix が多いか |
4. 優先度マトリクス
高リスク 低リスク
┌──────────────┬──────────────┐
高変更│ P1 │ P2 │
頻度 │ 最優先で書く │ 書く │
├──────────────┼──────────────┤
低変更│ P3 │ P4 │
頻度 │ 次に書く │ 書かなくて可 │
└──────────────┴──────────────┘
リスク = 複雑度 + 依存の広さ + 境界性 + 歴史的障害 の合成。
5. レポート形式
# テストギャップ分析: <スコープ>
## 優先度 P1（最優先）
| ファイル / 関数 | 複雑度 | 変更頻度 | 依存元 | 境界 | 障害歴 | 提案 |
| --- | --- | --- | --- | --- | --- | --- |
| `<path>::<func>` | 高 | 高 | 15 箇所 | DB | 3 件 | Unit + Integration |
### 補足
- `<path>::<func>` は <理由>。特に <条件> のテストがない。
## 優先度 P2
...
## 優先度 P3
...
## 今回は対象外（P4）
- <path> — <理由: 削除予定 / 自動生成 / 十分にカバーされている>
## 推奨ステップ
1. P1 のうち `<top>` から着手（工数目安: X 時間）
2. `backend-test-planner` で詳細ケース設計
3. `backend-test-writer` で実装
6. ユーザー確認
- 優先度付けが妥当か
- 着手する P1 をどれにするか
- P4（やらない）の判断に異論はないか
やらないこと
- カバレッジ 100% を目指すリスト作り（価値の低いテストが量産される）
- 機械的にテストファイルがないものを全て列挙（人間の判断を差し込む）
- テストの実装（別スキルに委譲）
指標の注意
- カバレッジ数値は指標であって目的ではない
- 「テストの本数が多い」より「変更時に壊れて教えてくれる」 ことが価値
- プロパティベース / スナップショットテスト が既にあるなら、そのギャップも見る
関連
ギャップ検出時は unit / integration の両面を見ること。単体テストだけ充実して integration がないと DB マッピング・エラー変換・トランザクション境界のバグを拾えない。
