コストを意識したテスト検証
冗長な作業と出力を削減しつつ、必要な検査を弱めないでください。適切な順序を選択することで実行時間を節約でき、簡潔なレポートはコンテキストを節約しますが、すでに実行中のテストを高速化するものではありません。測定なしに節約を主張しないでください。
チェックの計画と実行
- 高価なスイートを実行する前に、影響を受けるコンポーネント、リスク、プロジェクト要件、適切なチェックを特定してください。明示的なユーザーとプロジェクトの要件（必須チェックを含む）に従ってください。
- まずコアとなる変更と意味のあるターゲットを絞った回帰テストを完了してください。最も狭い関連チェックでビルドまたは動作の失敗を診断し修正します。その後、影響を受ける統合またはエンドツーエンドのシナリオを安定化させます。新規または変更された共有シナリオについては、利用可能なリファレンスと期待値を比較し、意図的な差異は個別に検証して文書化します。
- 変更とターゲットチェックが安定したら、必要に応じて必須の最終スイート、静的チェック、ビルドを実行します。成功結果は、関連するコード、依存関係、設定、環境、シナリオが変更されていない場合にのみ再利用します。
- 修正後は、影響を受けるチェックを再実行します。影響範囲が広い場合、依存関係が変更された場合、要件がそれを要求する場合、または正しさが不確かな場合は、広範なスイートを繰り返します。局所的な失敗ごとに自動的にフルスイートを繰り返さないでください。
- 断続的な失敗の場合は、最初の失敗を保持し、テストを単独で再実行します。必要に応じて、干渉を調査するためにスイートをシリアルに実行します。後続の成功をもって失敗が修正された証拠とするのではなく、解決されていない不安定性を報告します。
- ドキュメントのみの変更の場合は、差分、関連リンク、構文を確認します。必要な場合または関連する場合にのみアプリケーションテストを実行します。パフォーマンス測定は、結果を歪める可能性のある同時ビルドやテストから分離してください。
- 長時間実行されるジョブは、変更されていない出力を繰り返し読み取るのではなく、適切な間隔でポーリングします。進捗を確認するためだけに作業を再開しないでください。
出力を有用かつ制限されたものに保つ
既存のプロジェクトランナーまたはフレームワークのレポート機能を優先してください。適切な場合、完全なstdoutとstderrを一意で上書きしないログにキャプチャし、簡潔なサマリーを返します：コマンドの結果と終了ステータス、所要時間、スキップまたは無視されたテストを含む認識可能なテスト数、ログの場所。失敗時には、失敗したケース名と制限された診断抜粋を含めます。サマリーが不十分な場合は、完全なログの関連部分を検査します。部分的なスイート数から全体の成功を推測しないでください：コマンドの実際の終了ステータスを使用し、サマリーを解析できない場合はその旨を明記します。起動エラー、キャンセル、シグナル動作を保持します。既存のランナーの周りに冗長なラッパーを積み重ねないでください。
テストインフラの検証
テストランナー、ラッパー、またはレポートツールを作成または大幅に変更する場合は、その結果の信頼性をテストします。ツールが実際に行うことと、失敗を隠蔽または誤って表現するリスクに基づいてケースを選択します。有用なケースは次のとおりです：
- 成功したスイートの後の後続の失敗は、正しい終了ステータスで失敗のままです。
- 表示される診断が制限されている場合でも、完全な出力は保持されます。
- スキップ、起動エラー、認識されないサマリー、割り込みは、該当する場合、適切に報告または伝播されます。
観察可能な動作を実行し、基盤となるテストプロセスとの境界を含めます。解析を実際のフレームワークに適応させ、実装を単に複製するテストは避けてください。これはインフラの検証であり、個々のテストごとにテストを書く要件ではありません。このスキルが使用されているという理由だけで、信頼できる既存のツールを書き換えたり再テストしたりしないでください。
診断テストの作成
合格するテストは、進捗出力が有用でない限り、静かにしておきます。失敗は、ケース、期待される動作と実際の動作、関連パラメータ、ランダムシードを特定する必要があります。大きなペイロードは、すべてをダンプする代わりに、長さ、不一致の場所、短い抜粋、またはハッシュで説明します。必要に応じて、診断のために反復ごとの詳細または完全なトレースを有効にします。スキップは理由を明示してマークし、決して失敗を成功終了に変換しないでください。既存のノイズの多いテストに取り組む際に改善し、フォーマットのためだけに健全なスイートを書き換えないでください。