backend-test-gap-finder

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% を目指すリスト作り（価値の低いテストが量産される）
機械的にテストファイルがないものを全て列挙（人間の判断を差し込む）
テストの実装（別スキルに委譲）

指標の注意

カバレッジ数値は指標であって目的ではない
「テストの本数が多い」より「変更時に壊れて教えてくれる」 ことが価値
プロパティベース / スナップショットテスト が既にあるなら、そのギャップも見る

Test Gap Finder

いつ使うか

実行手順

1. 対象範囲の決定

2. カバレッジ情報の取得（ある場合）

3. リスク評価軸

4. 優先度マトリクス

5. レポート形式

6. ユーザー確認

やらないこと

指標の注意

関連