audit-tests

テストの監査

テストを独立した証明として監査します。このテストがなくなった場合、どのバグを見逃すでしょうか？ その結果、契約と、それを満たす現存テストの対応表ができ、維持、修正、統合、削除の判断材料となります。テストの数を減らすことが目的ではありません。同等以上の信頼性を、より少ない保守負担で実現することが目的です。

テストの書き方や、テストを反証する方法はwrite-testsが担当します。このスキルでは、そのテストが新たな証明を加えるか、また、その証明をどこに置くべきかを判断します。変更の最終確認はreviewが担当します。

ワークフロー

1. 監査の範囲を定めます。 リポジトリと適用範囲の指示を読み、対象となるプロダクションコードの責務を選びます。関連するテスト、フィクスチャ、共有スイート、CI の選択ルールを見つけます。編集前に、開始時のリビジョン、ローカルの変更、テスト結果を記録します。既存の失敗と、実行できなかったチェックを区別します。対象を絞った監査では、根拠のある候補をいくつか選びます。サブシステム全体を調べる場合は、以下の完全性に関するルールに従います。
2. 主張の根拠をたどります。 各候補を、パラメーター行も含めて最後まで読み、プロダクションコードのエントリーポイントと、その先で呼び出されるコードを確認します。呼び出し元、同種の実装、重複するカバレッジ、テストの存在理由を説明する履歴を調べます。主張の根拠が依存関係の動作にある場合は、その依存関係のコードや型も確認します。テスト名が別のことをうたっている場合でも、アサーションが実際に検出する内容を記録します。
3. 編集前に判定を記録します。 以下の根拠記録を使います。判明した内容は、その都度共有してください。重要な発見を伏せたままワークフローを進めてはいけません。監査のみを求められている場合は、この根拠と変更案を提示して終わりとし、削除は行いません。
4. 証明を引き継ぐテストを選びます。 個々の弱いアサーションだけでなく、重複する層全体を記録から確認します。各契約を担当するスイートと、そこに取り込むべき固有のケースをすべて明記します。内部の協調オブジェクトを再現するより、外部依存を制御した実際の経路を優先します。別の層にカバレッジを持たせるのは、選んだ担当スイートでは検出できない失敗、たとえばルーティングやライフサイクルの動作を検出できる場合に限ります。
5. 一貫した境界をひとつ変更します。 実装の変更が対象に含まれる場合は、古いテストを削除する前に、write-testsを使って固有のケースを引き継ぎ先のスイートに移します。セットアップを複製するのではなく、既存のケースやフィクスチャを拡張します。同じ変更の中で、新たに不要になったテスト用フックや補助コードを削除します。エクスポート、ラッパー、リセット関数、グローバル変数、注入パラメーターを削除する前に、プロダクションコードでの利用箇所を確認します。スイートを移す場合は、テストの検出方法と CI への登録も更新します。
6. カバレッジが保たれていることを証明します。 削除したアサーションと引き継ぎ先のアサーションを比較し、契約の漏れや、意図した理由で失敗しないアサーションがないか確認します。write-testsを使い、修正または移行した回帰テストが、適切な変更によって失敗することを確認します。一時的なプロダクションコードの変更は切り分け、ほかの作業に影響を与えず元の内容を復元したうえで、対象となる証明が通ることを確認します。ベースラインの失敗は別に報告し、新たな失敗があれば調査します。担当スイートと関連スイートを実行した後、リポジトリで必須のチェックを実行します。静的チェックを置き換える場合は、チェック対象とされていた実際のコマンドまたはドライランを実行します。ランナーがファイルを読み取っている間は、ファイルを変更せず安定した状態に保ちます。
7. 変更を完了します。 reviewを実施してから、出荷した内容に合わせて根拠記録を更新します。未解決の失敗や未実行のチェックは明示して報告します。テストスイートが小さくなり、すべて成功しただけでは、削除したカバレッジに冗長性があった証明にはなりません。契約の対応表と、カバレッジが保たれた根拠が必要です。

エビデンス記録

各候補について、場所と名前、実際に検出できる不具合、その存在理由、関連するフックを利用する本番コード、および判断を記録してください。

• 維持： 独立して保護する契約を特定してください。ファイルを移動しただけでは、この判断は変わりません。
• 修正： 契約は維持したまま、弱い、誤解を招く、または誤った境界に結び付いているアサーションを置き換えてください。
• 統合： 統合先のテストスイートと、元のテストをなくす前に証明すべき固有のケースを特定してください。
• 削除： より強い証明が残ることを特定するか、保護すべき契約が存在しないことを示してください。重複しているという疑いだけでは不十分です。

根拠となるソースや履歴、可能になるクリーンアップ、リスク、および検証コマンドを含めてください。根拠が不足している場合は削除せず、未解決の問題として残してください。

誤った安心感

次の項目は調査のきっかけとして使い、自動的な削除ルールにはしないでください。

• 循環した根拠。 期待される出力がテスト対象のヘルパーから得られている、フィクスチャが本番コードのインベントリをコピーしている、テストが値とその値自身を比較している、といったケースです。実装に依存しない期待値を見つけてください。
• 主張のない実行。 行を実行する、識別子をコピーする、エクスポートを一覧表示するといったことは、信頼できる不具合を検出せずにカバレッジを増やす場合があります。実行そのものが意味のある何かを担保しているか判断してください。
• ハーネスが役割を果たしている。 モックが約束された振る舞いを実装している、フィクスチャが本番コードで生成すべき応答や順序を与えている、あるいは永続化のアサーションが実際の経路では書き込まれないストアを読み取っている、といったケースです。異なる依存 API に同一のフェイクを使うと、その違いが隠れることがあります。
• 異なる原因で失敗する。 否定ケースが別のガードに引っかかる、または意図した分岐に到達しない、といったケースです。何かが入力を拒否したことだけでなく、失敗条件を確認してください。各パラメーター行が、それぞれの主張を実際に検証しているか確認してください。
• 振る舞いを装う宣言。 ソースコードの検索、インポート一覧、機能フラグ、内部の呼び出し形式は、宣言を証明できても、ユーザーの利用経路が壊れている場合があります。宣言が約束する振る舞いをたどってください。
• 同じ証明の繰り返し。 プライベートヘルパーのテスト、共有ロジックをプロバイダーごとに再実行するテスト、同じ回帰を複数の層で検証するテストは、いずれも一つの契約を保護しているだけかもしれません。異なるファイル名で同じシナリオを繰り返すのではなく、異なるトランスポートやライフサイクルのリスクを維持してください。
• テストがコードを存続させている。 テストから呼び出されることだけを理由にヘルパーや本番コードの回避策が存在する場合です。実際のエントリーポイントに証明を移し、使われなくなった仕組みを削除してください。別のテスト専用抽象化に置き換えてはいけません。

維持する価値があるもの

振る舞いには、互換性や運用上の契約も含まれます。API と SDK の形状、ワイヤー上のバイト列、プロンプト、デフォルト値、設定、マイグレーション、ストレージ、セキュリティ、プラットフォームの振る舞い、生成物における言語間の整合性、パッケージの内容、リリース規則、アーキテクチャ上の境界が該当します。静的アサーションが、そうした契約を独立して証明する最も簡単な方法である場合もあります。観測可能な順序も、ここに含まれます。

内部の名前を変更してもテストが機能し、外部への約束が壊れたことを検出できるかを確認してください。プロトコルではバイト列の完全一致が不可欠な場合がありますが、通常、プライベート識別子の完全一致は必要ありません。遅いことも、実装に似ていることも、削除の十分な根拠にはなりません。実際の契約を直接検証できるなら、リファクタリングに影響されやすいカバレッジを追加しないでください。

既存の失敗は、製品の不具合である可能性があります。再現して調査してください。監査を成功させるために、正当な主張を削除してはいけません。対象範囲内の不具合は別途修正し、同じハーネスで、修正前に失敗し修正後に成功することを確認してください。無関係な不具合はフォローアップとして記録し、そのカバレッジを維持してください。

サブシステム全体の一括整理

編集を進める前に、整理対象を把握します。

• 共有スイートや統合テスト、QA、実環境のハーネスに含まれるケースも含め、管理対象のテストをすべて洗い出します。ファイル名の接頭辞と一致しない場合も、それぞれを本番コードの責務に割り当てます。ベースラインの結果と、テストおよびサポートコードの規模を記録します。
• すべての宣言について、判断とその根拠を記録します。パラメーター表の全行が同じ判断に値する場合に限り、1つの記録にまとめられます。その後、記録をもう一度確認し、残すスイートと廃止するレイヤーを選定します。
• エージェントを利用できる場合は、責務ごとに読み取り専用の調査を委任します。共有フィクスチャの編集は1人の担当者に限定します。各バッチで、説明のつかない失敗を新たに発生させてはいけません。記録済みのベースライン失敗は、修正に向けて見える状態に保ちます。
• 独立したレビュアーに、削除したカバレッジと新たな担当箇所を照合してもらいます。報告されたすべての不足について、証明を復元するか、ソースコードを根拠に不要と判断することで解決します。復元した各契約が、意図的に仕込んだ欠陥を検出することを実証します。
• ベースブランチが進んだ場合は、削除対象のファイルに新たに追加されたケースを調べ、その契約を引き継ぎます。リポジトリの統合ポリシーに従い、変更後のリビジョンでサブシステムと必須の統合チェックを再実行します。次のバッチに着手する前に、調査結果を更新します。

完了

契約マップ、判断とその理由、本番コードの簡素化、意図的に残した価値あるテスト、カバレッジ維持の不足とその解決策、実際に実行した検証を引き継ぎます。広範な一括整理では、本番コード、テスト、サポートコードそれぞれの整理前後の規模に加え、残りのバッチと統合の状況も記載します。規模は成果を表すものであり、削除目標を決めるものではありません。洗い出し項目に未確認のものがない場合に限り、サブシステムの監査が完了したとします。