test-audit

テストスイートの監査

ステップ 1：範囲を確認する

依頼にすでに範囲が記載されている場合は、ステップ 2 に進んでください。それ以外の場合は、次のように質問します。

どの範囲を監査しますか？

1. 特定のファイル — テストファイルのパスを指定してください
2. 変更されたファイルのみ — main との差分に含まれるテスト（新規または変更されたテスト）を監査します
3. プロジェクト全体 — コードベース内のすべてのテストファイルをスキャンします

また、テストとの照合に使う仕様、Issue、または必須テストケースのリストはありますか？

回答を待ちます。範囲が確定し、仕様の有無がわかったら完了です。

ステップ 2：コンテキストを収集する

プロジェクトのテスト設定、パッケージスクリプト、CI ファイルを読み、フレームワーク、テストコマンド、テストファイルを確認します。その後、対象範囲内の各テストファイルについて、以下を収集します。

• テスト対象のコード — コードを読みます。テストの問題の多くは、本番コードに起因します
• 仕様 — ユーザーのケースリスト、PR の説明、リンクされた Issue、仕様書または計画ファイル
• 履歴（差分の監査）— コードの削除のみを行ったコミットで追加されたテスト

テストコマンド、対象範囲内のテストファイル一覧、および各テストファイルが検証する本番ファイルが揃ったら完了です。

ステップ 3：監査基準を適用する

対象範囲内の各テストに対し、references/audit-criteria.md のすべてのセクションを適用します。各セクションを各ファイルに照らして確認し、Design の指摘（テスト容易性と設計のシグナルを扱うもの）や仕様とのギャップ（仕様へのトレーサビリティを扱うもの）を生じさせるセクションも含めて、すべて確認したら完了です。

ステップ 4：テストの強度を測定する（任意）

その言語にミューテーションテストツールがある場合は、監査対象に対して実行するか確認します。実行する前に references/mutation-testing.md を読みます。前提条件、ツールのフラグ、生き残ったミュータントの分類方法が記載されています。ユーザーが辞退した場合、またはツールがない場合、監査は静的監査のみです。

ステップ 5：指摘事項を報告する

基準セクションで独自の重大度が定められていない限り、重大度は次のとおりです。

• HIGH — テストが、主張する動作が壊れていても成功する可能性がある場合、または必須のエラーケースやセキュリティケースにテストがない場合
• MEDIUM — テストが弱い、壊れやすい、または誤解を招く場合。バグを見逃したり、リファクタリングで壊れたりする可能性があります
• LOW — 命名、構成、スタイル

指摘事項ごとに、以下を示します。

### [HIGH | MEDIUM | LOW] [Test | Design] Issue Title

**File**: `path/to/test_file.ext`
**Test**: `test name`
**Lines**: X–Y

**Problem**: What's wrong

**Current**:
[code snippet]

**Fix**:
[corrected code]

**Why**: One-sentence rationale

Design の指摘では、File に本番ファイルを指定し、Fix に本番コードの修正内容を記載します。その後に、短期的なテストの修正案を記載します。

ステップ 6：要約する

次の項目で締めくくります。

1. 重大な問題 — HIGH の指摘事項
2. 品質上の問題 — MEDIUM の指摘事項
3. スタイル上の問題 — LOW の指摘事項
4. 設計上の指摘事項 — テストを簡潔にする本番コードの変更
5. テストの強度 — ステップ 4 を実施した場合：ツール、対象範囲、成果につながらなかった生き残りミュータント（スコアは参考情報のみ）。それ以外の場合は「静的監査のみ」
6. 全体的な健全性 — 1 段落
7. 優先事項トップ 3～5 — 影響の大きい改善
8. 推奨テストリスト — 不足している各ケースを、エージェントへの次のプロンプトにそのまま貼り付けられる given/when/then の 1 行で記載