prune-tests

テストの整理

重要な保護を弱めることなく、テストスイートの実行コストを削減します。

残すテスト

次のいずれかを独自に保護する場合に限り、テストを残します。

• 他のリポジトリ、サービス、ユーザーが依存する契約。
• 再発する可能性のある、リリース済みのバグ。
• 重要なセキュリティ、権限、互換性、並行処理、移行、プロトコル、またはデータ損失に関する不変条件。これを強制する分岐ごとではなく、不変条件ごとにテストを1つ残します。

また、リポジトリの指示で必須とされているテストはすべて残します。

契約とは、API、CLI、プロトコル、ワークフロー、または成果物の境界にあるものです。バグがデフォルトブランチまたはユーザーに到達した場合、そのバグはリリース済みです。内部の仕組みを対象とするテスト、より強いテストと重複するテスト、同等のケースを網羅的に列挙するテスト、使われなくなった動作を維持するテスト、フレームワークや型の保証をテストするもの、コードをそのままアサーションに書き直したもの、動作ではなく構造に依存するものは該当しません。テストを残す理由として、カバレッジ率は認められません。

対象範囲

デフォルトではテストスイート全体を対象とします。呼び出し元が差分に対象を絞っている場合は、差分で追加または変更されたテストと、変更または削除されたコードを対象とするテストのみを検討します。

ワークフロー

1. 対象範囲のテストを実行し、所要時間を記録します。失敗したテストがあれば、そこで中止して失敗内容を報告します。
2. Keep の基準に照らして、対象範囲内のすべてのテストを、保護する対象ごとにグループ化します。何も保護していないテストは1つのグループにまとめます。
3. 保護する対象が不明確なグループを調査します。そのテストを追加した修正を履歴から探し、対象のコードとその呼び出し元を読みます。また、アサーション対象の動作を一時的に壊し、別のテストも失敗するか確認します。履歴からデフォルトブランチまたはユーザーに到達したことが確認できる場合に限り、バグをリリース済みとして扱います。
4. 各グループを keep、consolidate（同じ保護内容を持つ1つのテストに統合）、または delete に分類します。独自に保護する対象を特定できないグループは削除します。すべてのグループに分類を付けたら完了です。
5. 本番環境の動作を変更せず、グループごとに1つずつ変更を適用します。
6. 対象範囲のテストと、削除したフィクスチャを使っていたすべてのテストを再実行します。すべて成功したら完了です。

削除および統合したテスト、フィクスチャ、行数、削減できた実行時間と、各削除・統合の理由を報告します。