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