テスト削減監査

保証の価値に見合わないテストを積極的に見つけ、削除・統合候補をすべて列挙する。判断の中心は 「このテストを削除すると、どんな現実的な不具合を見逃すか」 とする。「念のため」、テスト件数、カバレッジ維持自体を残す理由にしない。削減件数も目標にせず、候補がなければその根拠を示す。

範囲と調査

• 指定がなければ現在のrepositoryが管理する全テストを対象にする。依存パッケージ、生成物、外部参照用submoduleは通常除外し、除外範囲を明記する。
• 適用される開発契約と既存差分を確認する。test runner設定、workspace構成、CI、実行スクリプトからテストの入口を把握し、ファイル名検索だけで全件を把握したとみなさない。inline test、E2E、snapshot、parameterized test、独自検証スクリプト、skipされたテストも確認する。
• 対象ファイルを一覧化して確認済み／未確認を追跡し、目立つ数件の抽出で終了しない。大きな対象は領域ごとに進める。途中終了時は未確認範囲を残し、全件精査済みと報告しない。
• テスト本文、対象の実装、呼び出し元、fixture／mock、関連する製品契約を必要な範囲で読む。テスト名やassertion数だけで判定しない。
• 実行時間、不安定さ、修正負担は既存の実行結果や変更履歴などから確認する。測定値と推定を区別し、未測定の時間や失敗率を捏造しない。監査のためだけに全suite実行や大規模な計測を必須にしない。

削除・統合の観点

対象	判断の要点
実装のコピー	期待値の計算が本体と同じロジックを再実装し、同じ誤りを共有していないか。独立した仕様上の期待値や別方式の参照実装とは区別する。
モックの自己検証	設定した戻り値や呼び出しをモック側だけで再確認していないか。本体を通じた引数・副作用・外部境界の契約を検証するモックには独自の価値があり得る。
型・ライブラリの保証の再確認	有効な型チェックや使用中のライブラリが既に保証する性質を再確認していないか。外部入力、永続データ、設定、ラッパー、接続方法の誤りはその保証の外にある。
他テストとの重複	同じ現実的な不具合を、残すテストも同じ前提で検出できるか。似た入力や同じ関数名だけで重複としない。unitとintegrationで配線・環境・状態の保証が異なる場合がある。
内部実装への過度な依存	private state、内部関数の呼び出し順、DOM構造など、挙動を保つ変更で壊れる検証か。ただし順序や回数自体が二重送信防止などの外部契約なら保護対象になる。
過剰なケース分け	同じ同値クラスの値だけを大量に変えていないか。境界値、異なる失敗経路、権限、状態遷移、再試行・競合など、別の不具合を検出するケースを区別する。

静的な文言・style・巨大snapshotも、具体的な契約を守るassertionと、変更負担だけを増やすassertionに分ける。正確な文字列がprotocol、保存形式、error code、アクセシビリティ契約なら、その保証を考慮する。

候補の採否

各候補について、以下の因果関係を説明する。

1. 失う保証: 起こり得るコード変更や入力・状態を挙げ、このテストだけが検出する不具合を特定する。説明できなければ「独自に検出する現実的な不具合を確認できない」とし、根拠のない保険扱いで残さない。
2. 残る保証: 代替になる具体的なテストとassertion、型チェックなどを示す。それが実際に対象コードを通り、該当条件を検出し、必要なCIや実行経路で動くか確認する。代替がない場合も明記する。
3. 費用対効果: 不具合の起こりやすさ・影響と、実行時間・不安定さ・修正負担を比較する。重い／不安定というだけで、独自の重要な保証を削除しない。一方、保証が乏しいテストに代替の新規作成を機械的に要求しない。
4. 最小の整理: ファイル全体、個別ケース、assertion、parameter行のどこを削るかを示す。統合では残す代表ケースと固有assertionの移し先を指定する。無関係なシナリオを巨大な一つのテストにまとめない。parameter化による記述重複削減と、実行ケース削減は区別する。

重複候補は集合として評価し、互いを代替扱いして全削除しない。残す側を一つ以上明示し、候補をまとめて適用しても必要な保証が残ることを確認する。過去の不具合の再発防止テストも特別扱いで永久保存せず、現在の到達可能性と代替保証を確かめる。

判断に必要な実装や契約が未確認なら、不足する証拠を明記して「要確認」にする。保留を「念のため残す」の置き換えにせず、確認可能なものは調査中に解消する。

出力と完了

結果は日本語で、次の順にまとめる。候補が多い場合も上位数件だけに省略せず、必要なら利用者指定の出力先に全件を保存する。

• 確認範囲: テストの入口、確認済み範囲、除外・未確認範囲。件数を出す場合はファイル数／実行ケース数などの単位を明記する。
• 削除・統合候補一覧: 各行に対象のpath・line・test名、判定（削除／統合／条件付き）、該当観点と根拠、削除で見逃す不具合、残すテストまたは保証、削減できる負担を記載する。条件付き候補には適用前の具体的な条件を付ける。
• 統合後の姿: 重複グループごとの残すテスト、移すassertion、削るケース。候補を同時適用した際の保証を示す。
• 残す判断・要確認: 削除候補に見えたが独自の保証があるものと、不足する証拠を簡潔に示す。全保持テストの長い解説は不要。

既定は監査と候補提示までとし、テストを編集しない。利用者が削除・統合の実施も依頼している場合は、根拠が揃った候補を実装し、影響する残存テストと必要な型チェック等で検証する。既存の失敗と今回の変更による失敗を区別し、通過だけを保証維持の証拠にしない。製品コードの挙動変更、skip化、assertionの無効化、カバレッジ閾値の引き下げで帳尻を合わせない。

全対象の確認と候補間の整合確認が終わったら完了する。通常の棚卸しにStory、PLAN、専用台帳、独立レビュー、サブエージェントを自動追加しない。