統合テストを削除するのに十分な単体テストカバレッジがあるかどうかを確認するにはどうすればよいですか？
私はレガシーシステムに取り組んでいます（つまり、テストなしで作成されたという意味です）。外部から機能をテストする統合テストを作成して、システムの一部をテストしようとしました。
これにより、コードを壊すことを心配することなく、コードの一部をリファクタリングできる自信が得られます。ただし、問題は、これらの統合テストのデプロイ（2分以上）と実行に数分かかることです。また、維持するのが面倒です。それぞれが数千行のコードをカバーしており、そのうちの1つが壊れると、その理由をデバッグするのに1時間以上かかることがあります。
私は最近行ったこれらの機能変更のためにたくさんの単体テストを書いていますが、コミットする前に、私は常に新しいデプロイを実行してすべての統合テストを実行します。この時点で、単体テストと一部の統合テストが、それらのテストと重複していることがわかりました。
良い単体テストが悪い統合テストを適切にカバーしていて、その統合テストを削除できるようになっていることをどのようにして知ることができますか？
最も簡単な測定基準は、「この統合テストが最後にいつ合法的に失敗したのか？」統合テストが失敗してから長い時間が経過している場合（多くの変更があった場合）は、単体テストが十分に機能していると考えられます。統合テストが最近失敗した場合は、単体テストで検出されなかった欠陥がありました。
私の好みは、通常、統合テストの堅牢性を高め、無人で確実に実行できるようにすることです。実行に時間がかかる場合は、一晩実行します。たまにしか実行されない場合でも、それらは依然として価値があります。これらのテストが非常に脆弱であるか、手動による介入が必要な場合は、テストの実行に費やす時間に見合う価値がない場合があり、最も成功するテストを破棄することを検討してください。
単体テストはテストの聖杯ではありません。それらは、コードベースのテストに使用する必要があるツールの1つにすぎません。したがって、他のテストを置き換えるのに安全であると見なされるユニットテストはありません。悪い統合テストがある場合は、それを優れた統合テストにするために取り組む必要があります。それを他のもので置き換えないでください。これは、正面ドアを境界フェンスとゲートで置き換えるようなものです。