アサーションを使用するjUnitテスト(T1と呼びましょう)があります。そのアサーションが何らかの価値を持つためには、そのアサーションが正しいことを確認するバリデーターが必要です。
バリデーターについては、別のテストスイートにテスト (T2) があります。どうにかして T2 を T1 の前提条件にすることはできますか。
それが不可能な場合、T1 と T2 が同じスイートにあれば可能でしょうか?
アサーションを使用するjUnitテスト(T1と呼びましょう)があります。そのアサーションが何らかの価値を持つためには、そのアサーションが正しいことを確認するバリデーターが必要です。
バリデーターについては、別のテストスイートにテスト (T2) があります。どうにかして T2 を T1 の前提条件にすることはできますか。
それが不可能な場合、T1 と T2 が同じスイートにあれば可能でしょうか?
前提条件が発生しない場合、単体テストをスキップすることを考えます。コード化されたロジックによって単体テストをスキップすることは危険です。なぜなら、問題があるかどうかがわからず、コードがテスト カバレッジを得られないからです。基本的な部分が壊れている場合は、エラーを隠すよりも、より多くのテストに失敗する方がよいでしょう。単体テストについて話していることに注意してください。これは、独立していて、ソフトウェアの小さな部分をテストする必要があります。
プロダクション コードの一部ではないエタロン バリデーターを使用できますが、確実にテストを実行することを妨げない単純なテスト ユーティリティでなければなりません。前提条件のためにテストコードが重要なコード部分をスキップするという理由だけで、バリデーターに接続されていないコードに別のエラーが発生する可能性があり、それが発生するのが遅れる可能性があるという最悪の事態.
実際に統合テストや機能テストを行いたい場合は、JUnit 以外のテスト フレームワークの使用を検討する必要があります。統合テストでは、テストの残りの部分をスキップして、統合環境の悪用を数分または数時間停止することが理にかなっている場合がありますが、単体テストでは、コードのすべての部分を制御する必要があります。
もちろん、JUnit でも前提条件をハックできます。たとえば、@BeforeClass/setUp フィクスチャでアサーションを作成したり、テストに「if」フォークを配置したりできますが、だまされます。
T1 にコメントして、合格は T2 に依存しており、T2 も失敗した場合は、T1 に取り組む前に最初に修正する必要があることを説明できます。