これについて合意された「現在の知恵」があるかどうかはわかりませんが、ここに私の2セントがあります.
まず、@codebox が指摘したように、単体テストを互いに独立して実行する必要があるため、単体テストごとにモックを再作成することをお勧めします。そうしないと、一緒に実行するとテストに合格しても、単独で実行すると失敗する (またはその逆) 可能性があります。テストに必要なモックの作成は、通常、テスト セットアップ ( [SetUp]
NUnit では、XUnit ではコンストラクター) で行われるため、各テストは新しく作成されたモックを取得します。
これらのモックの構成に関しては、状況とテスト方法によって異なります。私の好みは、必要最小限の構成で各テストでそれらを構成することです。これは、テストがその依存関係に何を必要としているかを正確に伝える良い方法です。これらの場合、いくつかの重複があっても問題はありません。
多数のテストで同じ構成が必要な場合は、シナリオ ベースのテスト フィクスチャ (リンクの免責事項: 恥知らずな自己宣伝)の使用を検討します。シナリオは のようなものである可能性がWhen_the_service_is_unavailable
あり、そのシナリオのセットアップでは、モックされたサービスが例外をスローするか、エラー コードを返すように構成できます。次に、各テストは、その共通の構成/シナリオに基づいてアサーションを作成します (たとえば、エラー メッセージを表示する必要がある、管理者に電子メールを送信する必要があるなど)。
構成の重複ビットが多数ある場合の別のオプションは、Test Data Builderを使用することです。これにより、モックやその他のテストデータのさまざまな側面を構成する再利用可能な方法が提供されます。
最後に、大量の構成が必要な場合は、テスト依存関係のインターフェースを変更して「おしゃべり」を少なくすることを検討する価値があるかもしれません。テスト対象のクラスに必要な呼び出しの数を減らす有効な抽象化を探すことで、テストで構成する必要が少なくなり、そのクラスが依存する責任を適切にカプセル化できます。
いくつかの異なるアプローチを試して、何が効果的かを確認する価値があります。重複の除去は、各テスト ケースの独立性、シンプルさ、保守性、信頼性を維持することとバランスを取る必要があります。小さな変更で多数のテストが失敗する場合、または個々のテストに必要な構成を理解できない場合、またはテストが実行される順序によって失敗する場合は、次のことを行う必要があります。アプローチを改善します。