テスト監査 (Test Audit)
このスキルには2つのモードがあります:
- 作成 (Authoring). 以下に示す作成ゲートは、追加または変更するすべてのテストに適用されます。
- 監査 (Auditing). 低価値の証明を、生産コードの所有者ごとに一貫したバッチで削除します。削除数を追い求めないでください。目標は、各契約が1つの強力な所有者を持つスイートであり、単にテスト数を減らすことではありません。
サブシステム全体のテスト面を一度に整理するキャンペーンについては、最初にCAMPAIGN.mdを読んでください。
作成ゲート
テストを追加する前に、次の4つの質問に答えてください:
- どの観察可能な動作、不変条件、または独立した契約を保護しますか？
- どの信頼できる回帰がそれを失敗させますか？
- 既存の証明がそれをカバーしていない理由は？各契約は、最も強い境界で1つの主要な所有者を持つべきです。別のレイヤーでのテストは、それを正当化する独自のトランスポートまたはライフサイクルリスクを必要とします。ほぼコピーのようなテストを追加するのではなく、既存のテーブルと共有フィクスチャを拡張し、繰り返しのセットアップを統合してください。
- 本番コードの呼び出し元のないエクスポート、フラグ、ラッパー、またはインジェクションフックが必要ですか？もしそうなら、代わりに実際の境界で証明を行ってください。
補足ルール:
- 境界とコストガイドを使用して、テストがどこに属し、どの程度のコストを許容するかを決定してください。
- 回帰テストは、修正前に意図した理由で失敗し、修正後にパスする必要があります。修正前の失敗を示せない場合は、レポートでその理由を述べてください。
- バグが通過したすべてのレイヤーでテストを再現するのではなく、所有境界で1つの回帰テストで十分です。
- 動作を保持するリファクタリングはテストを壊してはいけません。
ジャンクパターン
- 自己比較、コピーされたインベントリ、ソースgrep、実装または呼び出し形状のアサーション、重複契約、テスト専用の継ぎ目、テスト対象によって生成された期待値、およびアサートされる動作を提供するモックを拒否してください。
- フィクスチャは、所有者が生成すべきレシートや順序を偽造してはならず、コードが決して書き込まないパスを通じて永続性を主張してはなりません。
- ネガティブコントロールは意図されたガードで失敗する必要があり、テストの名前は実際に実行する動作と一致しなければなりません。
- 監査候補を評価する際は、完全なチェックリストを使用してください。
保持基準
- 独立した契約を守るテストは保持してください: 公開API、SDK、プロトコル、設定、マイグレーション、ストレージ、セキュリティ、プラットフォーム、デフォルト、プロンプトバイト、生成されたクロス言語出力、パッケージング、リリース、アーキテクチャ、観察可能な順序。静的または低速であることはテストを削除可能にする理由にはなりません。
- ソース検査は、識別子のみのリファクタリングに耐え、独立したユーザー向け契約を守る場合にのみ許容されます。
- 失敗するベースラインテストは、削除するテストではなく、修正すべき製品バグである可能性があります。
監査と検証
- 監査編集の前に、候補の証拠とワークフローを読んでください。完全な所有者、呼び出し元、履歴を調査し、何かを削除する前に残っている証明を記録してください。
- 廃止された生産コードの継ぎ目は、そのテストと一緒に削除してください。削除数を最適化しないでください。
- テスト実行中はチェックアウトを編集しないでください。プロジェクトのフォーカステストコマンドを所有者と兄弟テストに対して実行し、プロジェクトの変更ファイルチェックを実行し、その後ランディング前にレビューを受けてください。
- 原因、保持された契約、証明とそのコスト、変更された本番コード行対テストコード行、およびフォローアップを報告してください。タスクがその権限を与えた場合のみ、コミット、プッシュ、またはランディングを行ってください。