test-audit

テスト監査

テストに存在価値があるのは、ほかの何にも見つけられない、現実に起こり得るリグレッションを検出できるときです。エージェントは小さな変更のたびにテストを書きますが、その多くはソースコードの再確認、モックを使ったより強力なテストの再実行、あるいは非公開の呼び出し形式の固定にすぎません。そうしたテストを削除してもカバレッジはほとんど変わらず、保守コストとスイートの実行時間は減ります。

• 該当するもの： ディレクトリを一通り調べ、価値が低い、配置が不適切、またはスキップされているテストを特定すること。また、カバレッジを維持しながら、サブシステム全体またはリポジトリ全体を測定可能な目標まで段階的に整理し、そうしたテストを存続させるためだけに残されているテスト専用の本番コードの接続部分も削除することです。
• 該当しないもの： テストが追加される前にゲートで止めることや、機能の差分をレビューすること（tidy）、分割やシャーディングによって CI を高速化すること（ci-speedup）、または未テストのコードにテストを書くことです。

モードを選ぶ

モード	適用場面	完了の条件
監査	指定されたファイルやディレクトリを対象に、範囲を絞って一通り調べます	信頼度の高い候補を少数、十分な根拠とともに特定し、検証が成功した状態で一貫したまとまりとして削除します
キャンペーン	サブシステムまたはリポジトリ全体のテスト範囲を対象とする場合、または「20%削除」のような目標がある依頼	目標を達成するか、達成できない理由を台帳に記録し、許容範囲内でカバレッジを維持し、保全レビューに合格します。最初に references/campaign.md を読んでください

開始前に目標を設定する

範囲を定めずに「テストを整理して」と依頼すると、明らかなテストをいくつか削除した時点で止まります。残った候補はどれも、単独で見れば正当化できるからです。監査にもキャンペーンにも、取り組むための数値目標が必要です。ユーザーが目標を指定している場合は、それを使用します。指定がない場合は、提案して、返答を待たずにその目標に沿って進めてください。

<scope> 内で価値が最も低いテスト宣言を20%削除し、行カバレッジと分岐カバレッジをベースラインから2パーセントポイント以内に保ち、残すテストをすべて成功させます。

まずベースラインを測定し（references/coverage.md）、目標に達するかカバレッジの予算を使い切るまで、価値の低い順に削除を続けます。残りの候補がそれぞれ明確な契約を守ることを台帳で示せる場合に限り、目標未達で終了しても構いません。目標は取り組み量の最低ラインであり、不確かなテストを削除する許可ではありません。以下の保持基準は、引き続き数値目標より優先されます。

不要なパターン

監査またはキャンペーンで探す対象は次のとおりです。

• アサーションのないカバレッジ確認や、例外が起こり得ない経路で「例外を投げない」ことだけを確認するテスト
• 自己比較、同一性を保つコピー、テスト対象のヘルパーやレンダラーが生成した期待値
• テスト自身が定義するデータのフィクスチャ、一覧、マニフェスト、エクスポートリスト、スナップショットの複製
• 名前変更では失敗する一方、実際の動作変更には影響されない、ソース、インポート、文字列の厳密な検索
• 実際の境界での確認と重複する、非公開の述語や呼び出し形式のテスト（内部関数に対する toHaveBeenCalledWith など）
• 1つの契約を重複して呼び出すテストや、共通ヘルパーをプロバイダーごとに再実行するテスト
• テスト専用のエクスポート、グローバル変数、ラッパーを維持することだけが目的のテストや、呼び出し元がテストしかない本番コード
• アサーション対象の動作を実装するモックや、複数の異なる API の代わりをする1つのモック
• テスト対象のコードが生成すべき順序、受領データ、コールバックを用意するフィクスチャや、その経路では書き込まれないストアに対する永続化の確認
• フラグが約束する動作を実際に試さず、宣言されたフラグをそのまま言い直す機能テスト
• 別のガードによる拒否など、無関係な理由で成功する否定的な確認
• アサーションが確認する内容を超える期待を持たせるテスト名。テストの題名ではなく、アサーションを基準に判断してください

配置場所の誤りとスキップされたテスト

もう 2 種類の指摘があります。どちらも、それだけを理由に削除候補にはなりません。また、移動やスキップ解除は、目標に向けた削除ではありません。

• 配置場所の誤り： テストがある所有者のテストスイートに置かれているものの、別の所有者だけをテストしています。たとえば、ルートに触れず、lib/slug.ts だけを呼び出す routes/posts.test.ts のスラッグ形式チェックです。保持するリグレッションについては、「編集の形」で述べたとおり、正規の所有者のテストスイートに移動してください。
• スキップされたテスト： it.skip('prorates refunds on downgrade')、xit、@pytest.mark.skip、t.Skip() など、テストが無効化されています。まずスキップを解除して実行してください。見つけた時点で削除してはいけません。成功した場合は有効なままにし、ほかのテストと同じ基準で判断してください。失敗した場合は、保持基準に照らしてプロダクトのバグの可能性として扱い、再現して所有者側を修正してください。実際のプラットフォームまたは環境上の理由による条件付きスキップは、指摘対象ではありません。

保持基準

テストが公開 API、プロトコル、設定、マイグレーション、ストレージ、セキュリティ、プラットフォーム、デフォルト値、生成された言語間の仕様、パッケージ、リリース、アーキテクチャ上の契約を単独で検証している場合は、保持してください。また、次のテストも保持してください。

• 順序が観測可能な動作である場合の呼び出し順序
• 信頼できる故障モードを示すリグレッション
• 独立したガードとして最も低コストのソース検査：ユーザー向けのキー、バイト、パスが変更されると失敗し、識別子だけの名前変更には影響されないもの
• ベースラインで失敗する保持対象のテスト：プロダクトのバグの可能性として扱い、削除するのではなく再現して所有者側を修正してください

静的であることや遅いことは、削除理由になりません。実装に似ているテストでも、契約を証明する唯一の手段である可能性があります。削除する前に、そうでないことを示してください。

候補ごとの根拠

判断する前に、テスト全体、本番コード上の所有者、その呼び出し元と呼び出し先、同等の実装、重複するテスト、およびテストが存在する理由を説明する履歴を確認してください。削除ごとに、次の事項を記録してください。

• テスト名と場所、および実際に検出できる障害
• 対象の継ぎ目を利用する、テスト以外の呼び出し元
• 残る、より強い証拠（保持するテスト名を明記）、または契約が存在しない理由
• 削除によって可能になる本番コードまたはテスト支援コードの削除
• 測定した場合は、削除によるカバレッジの差分

項目が欠けている場合、その候補はまだ準備ができていません。推測に基づく長いリストより、確信度の高い少数の削除を優先してください。件数を満たすために、不確かな候補を削除対象にしないでください。

編集の形

所有者の境界に沿ったまとまりで削除してください。各まとまりでは、それによって不要になるテスト専用のエクスポート、グローバル変数、ラッパー、リセットフック、不要な本番コードも、エイリアスとして残すのではなく削除してください。保持するリグレッションは正規の所有者へ移動し、重複するセットアップは共有フィクスチャにまとめてください。テスト行数だけでなく、本番コードの行数も純減させることを目指してください。同じ実装を言い換えるだけの代替テストは追加しないでください。

検証

1. 各まとまりについて、所有者と同等のテストを実行してください。
2. 削除したテストがソースを grep したりプランを検証したりしていた場合は、実際の契約を担うスクリプトまたはドライランを実行してください。
3. ベースラインと同じコマンドでカバレッジを再測定し、ファイルごとに予算と比較してください。
4. 本番コードとツールの行数をテスト行数と分けて、git diff --numstat を報告してください。

権限

テストとカバレッジのローカル実行、および作業ツリー内でのテストとテスト専用の継ぎ目の削除は、作業内容に含まれます。許可を求めずに実行してください。コミット、プッシュ、PR の作成は、依頼された場合に限ります。保持基準を満たすテストは残してください。それでも削除するかどうかはユーザーの判断であり、カバレッジのしきい値や CI ゲートを変更するかどうかも同様です。

引き継ぎ

• 目標、ベースライン、最終数値：宣言数または行数、行カバレッジ、分岐カバレッジ
• 削除したカテゴリと、その根本原因（こうしたテストが作られ続けた理由）
• テスト行数とは分けて数えた、本番コードの簡素化
• 保持した誤検知と、それぞれを残す理由
• 実際に実行した検証とその結果
• 今回の監査で実際に見つかったパターンに基づく、リポジトリの AGENTS.md 向けのゲート案。エージェントがこうしたテストを書かなくなるようにするもの

注意点

• パス上の唯一のアサーションを削除しても、その行をチェックせずに実行する別のテストが残っているため、行カバレッジは維持されます。カバレッジ上は削除しても問題なさそうに見える場合は、キーパーがその動作をアサートしていることを確認するか、対象に対してミューテーションテストを実行してください（references/coverage.md）。
• 集計カバレッジでは、無関係な領域のカバレッジが増えたことで、サブシステムが唯一の証明を失ったことが隠れてしまいます。削除したテストが触れていた本番ファイルごとに、ファイル単位で比較してください。
• ユニーク行カバレッジだけを基準に候補を順位付けすると、誤ったテストを削除してしまいます。ユニーク行がゼロのテストでも、その行に対する唯一のアサーションを保持している場合があります。ユニークカバレッジはテストを候補にするための指標であり、削除を決めるのは名前付きのキーパーです。
• 同じチェックアウトで Vitest または Jest をウォッチモードで実行しながらテストを編集すると、編集中のファイルが再実行され、削除によるリグレッションのように見えるエラーが発生します。一括作業の前にウォッチャーを停止してください。

参照ファイル

ファイル	読むタイミング
references/campaign.md	キャンペーンモードの場合、またはディレクトリをまたぐ、対象を指定した大規模なプルーニングを行う場合
references/coverage.md	ベースラインの測定、ファイル単位およびテスト単位のカバレッジ、予算チェック、ミューテーションによるスポットチェックを行う場合

メンテナンス専用：evals/evals.json には、このスキルを変更するためのシナリオとルーティングプロンプトが格納されています。タスクの実行時に読み込まれることはありません。

関連スキル

• tidy：差分でテストが追加または変更された時点でゲートし、差分の残りの部分とあわせてレビューします。このスキルは既存のテストスイート全体を調査するか、キャンペーン形式でプルーニングするだけです。「PR のこれらのテストを監査して」という依頼は、ここではなく tidy にルーティングされます。

クレジット

OpenClaw の test-audit スキルをもとにしています（openclaw/openclaw、MIT）。由来に関する情報は、リポジトリのメンテナンスノートに記載されています。