Test Coverage Guard

トリガー条件

キーワード（いずれか）

• 「テストレビュー」「テストの品質」「偽陽性」「false positive」「テストが信頼できない」
• 「モックが多すぎる」「カバレッジは高いのにバグが出る」「フレイキーテスト」「flaky test」
• 「テスト削除していい?」「このテスト意味ある?」「test review」「mutation testing」
• 「テストスイートが通っているのに不安」「テスト全部通るけど大丈夫?」

状況

• テストGREEN後、スイートの品質に不安がある場面
• PRレビューでテストコードの品質を確認したい場合

非対象（委譲先）

• テスト新規作成 → test-driven-development
• CI/CD設定 → ci-cd
• セキュリティテスト詳細設計 → security-review

前提条件

• レビュー対象のテストファイルが存在すること
• テストが実行可能な状態（環境構築済み）
• 対象プロジェクトの言語・フレームワークが判明していること

目的

偽陽性: 本来FAILすべきテストがPASSしている状態。緑でも本番で壊れるなら誤った安心感を与えるだけ。

本スキルはTDDサイクルを中断・上書きしない。不足発見時は「何が不足か」を報告しTDDスキルに委譲。

実行手順

Step 1: スコープ特定

⚠️ 対象100件超の場合、リスクベースで絞り込みを提案する。

Step 2: 偽陽性スキャン（P1→P2→P3順）

P1（即時修正）

パターン1: アサーション不足
コアロジックを return null に置換してもPASSするなら確定。戻り値・状態変化・副作用すべてを検証する。

パターン2: テストダブル過多
Mock2つ以上で要注意。合計5つ以上なら設計見直し検討。外部APIのみStub、DBは実物で状態を検証する。

パターン3: 呼び出し文脈の欠落
本番フローで前後処理がデータ状態を変える場合、その前処理を再現しているか確認。バッチ・パイプライン・ミドルウェアで起きやすい。

パターン4: privateメソッドの直接テスト
Reflection等でprivate直接テスト → publicメソッド経由の間接検証に置換。
例外（以下すべてを満たす場合のみ）:

1. 同機能の統合テストが既存でPASS
2. 純粋な計算ロジック（副作用なし）
3. 統合テストでは網羅困難な境界値
4. 抽出不適切の理由をコメント明記

P2（次スプリント）

パターン5: 正常系のみ
以下が不足していないか確認:

• 入力異常: null/空/0/負数/最大値/存在しないID
• 状態異常: 未認証・権限不足・論理削除済み・ロック中
• 外部依存異常: タイムアウト・接続エラー・レート制限
• 境界値: 境界-1 / 境界 / 境界+1 の3点セット

指摘のみ。テスト追加はTDDスキルに委譲。

P3（バックログ）

パターン6: テストデータと本番データの乖離
DB側デフォルト値・バリデーション・関連テーブル連動を再現しているか確認。重要データは本番と同じAPI/サービス経由で作成する。

パターン7: フレイキーの温床

⚠️ フレイキーテストは放置禁止。修正するか削除する。

パターン8: スナップショット形骸化
内容確認なしで --update-snapshot している場合。スナップショットは50行以下に保ち、重要部分は別途明示的にアサートする。

Step 3: ミューテーション思考実験

以下の変異を思考上で適用し、1つでもFAILしなければアサーション不足:

1. コアロジックを return null に置換 → FAILするか?
2. if条件を反転 → FAILするか?
3. 演算子変更（+→-、>→>=） → FAILするか?
4. 重要な副作用（DB保存・通知）をコメントアウト → FAILするか?

ミューテーションスコア目安: 80%以上（100%不要。等価ミュータントがあるため）

自動化ツール:

Step 4: テストダブル検証

チェックポイント

1. Mock数: 1テストあたり2つ以上で要注意
2. レスポンス一致: 型・フィールド名・ネスト構造が実際と一致しているか
3. エラーケース: タイムアウト・エラーレスポンス・不正データのStubが存在するか
4. 自プロジェクトのDB/クラスをテストダブルで差し替えていないか（実物が原則）

Step 5: 網羅性の指摘

• 正常系に対応する異常系テストが存在するか
• エラーレスポンスの型・メッセージ・ステータスと副作用の不在を検証しているか
• セキュリティ関連（未認証拒否・他ユーザーリソースへのアクセス拒否）のテストが存在するか
• 並行性関連（楽観ロック・在庫同時減算・冪等性）のテストが存在するか

不足テストの一覧をレポートに含める。実装はTDDスキルに委譲。

Property-Based Testing（JS/TS: fast-check、Python: Hypothesis）は既存テストの補完として有効。置き換えではない。

Step 6: レポート出力

## テストレビュー結果

### 🔴 要修正（偽陽性リスク: 高）
- **[テスト名]** — パターンN: [具体的な問題] → [修正方針]

### 🟡 改善推奨
- **[テスト名]** — パターンN: [具体的な問題] → [修正方針]

### 🟢 問題なし
- [テスト名]: [検証済みの観点]

### 📊 サマリー
- 検証テスト数: N / 要修正: N件 / 改善推奨: N件 / 問題なし: N件
- 不足テスト候補: [異常系・境界値テストの一覧 → TDDスキルに委譲]

禁止事項・制約

テスト削除の判断基準

削除してよい条件（いずれか該当 かつ 代替テストが存在/追加予定の場合のみ）:

1. 同層の他テストと検証内容が完全重複し、独自に検出できるバグがない
2. 過去6ヶ月でリファクタリング起因の修正が3回以上で、その間バグを1度も検出していない
3. テストダブルの保守コストが検出するリスクに見合わない

即削除すべきテスト:

カバレッジの正しい使い方

• 目標ではなくテスト漏れの発見ツールとして使う
• ラインカバレッジよりブランチカバレッジを重視する
• ミューテーションスコアを併用してテストの検出力を直接計測する
• CIゲートは「新規コード/変更コード」に限定する
• 未カバー行をテスト追加の候補リストとして活用する

関連スキルとの連携