依存性注入を使用して、テスト対象のクラス外のコードにモックを提供しています。テストしたいメソッドで使用されるAuthProvider、ConfigurationManagerなどをモックアウトする必要があるため、同じコードを何度も何度も書いていることに気づきました。メソッドには分岐 (if-then-else) が含まれているため、メソッドのすべての実行パスをテストするために複数のテストを用意しています。各モックを数回 (各テスト メソッドで 1 回) インスタンス化していますが、これは間違っているのでしょうか? また、すべてのメソッドで AuthProvider.Authenticate() などの呼び出しが呼び出されるため、明らかにほとんどがコピーアンドペーストであるモックとプリセット応答に期待しています。
各メソッドでモック リポジトリをセットアップし、各メソッドの最後でモック リポジトリを検証します。これらのモックを作成し、期待値と戻り値を設定するためのある種のファクトリを用意する必要がありますか?
モックの実装には RhinoMocks を使用しています。
「各モックを数回インスタンス化する」ことは問題ではありません。オブジェクトは無料です。
モック クラスを何度も定義していないことを確認してください。クラスは高価です。
また、TestCase には「setUp」メソッドがあり、すべてのテストで使用されるフィクスチャを作成できます。はい、テストごとに再構築されます。いいえ、それは非常に遅い場合を除き、問題ではありません。
NUnitを使用していると仮定すると、モックのインスタンス変数を使用して、セットアップ/分解でリセットできます。パターンが繰り返されている場合は、本番コードで行うことを実行します。達成しようとしていることを表すヘルパーメソッドをリファクタリングして抽出します（共通点がまったくない場合は、本番コードの設計に問題があります）。
セットアップに重要な区分がある場合は、本番クラスに複数のテストクラスを作成することを検討してください。
最後に、本番クラスが忙しすぎて、動作の一部をヘルパーオブジェクトに抽出する必要があるかどうかを考えてください。
テストを聞いてください！
これが私の見解です。
この場合、モックは使用しません...ファクトリメソッドを使用してクラスの偽の実装を返し、代わりに依存性注入を使用してこの実装を使用します。これにより、重複を回避し、この実装を再利用できます。 ...繰り返しますが、このファクトリ実装は適切にリファクタリングする必要があります。つまり、重複はありません。
モック、動的な動作をテストするときに使用する必要があると思います。たとえば、SUTでアクションを実行したときにサブシステムのメソッドが呼び出され、後でverify（）を呼び出してこの動作を検証しました。 .. Martin Folwer bliki Mock Aren'tStubsに関する良い記事もあります
モックコールに期待値を設定しないと、EasyMockのような記録および再生フレームワークは失敗します。しかし、Mockitoのようなフレームワークは、単にすべての呼び出しを記録し、重要なものだけを検証できるようにします。したがって、すべてのテストですべてのメソッドに期待値を設定する必要はありません。
そして、各テストメソッドでモックをインスタンス化するという問題に戻ると、setUp（）メソッドを使用するよりも良い方法があります。Mockitoは@Mockアノテーションを提供します。したがって、変数を（フィールドとして）次のように宣言します：@MockリポジトリrepositoryMock
setUp（）でinitMocks（）を呼び出すだけです。宣言されたすべてのモックオブジェクトは、明示的にモックを作成しなくても、テストで自動的に使用できます。