class - 単体テストで複数のモック オブジェクトを使用できますか?

Question

単体テストに関する多くの記事を読みました。記事のほとんどは、テストで複数のモック オブジェクトを使用すべきではないと述べていますが、その理由がわかりません。1 つのテストで複数のモック オブジェクトが本当に必要な場合があります。

Answer 1

コンテキストに応じて、単体テストに複数のモックを含めることができます。

しかし、「記事」が示唆しているのは

• オーバーモックの防止。ユニットテストですべての共同作業者をモックアウトするときは、ドアを開いたままにしておきます。実際の共同作業者を置き換えると、シナリオが失敗する可能性があります。モックの数を最小限に抑え、実行可能/可能な限り実際の共同作業者を使用することで、そのリスクを最小限に抑えます。
• 高結合度のアラート：単体テストを作成するために多くの共同作業者をモックする必要がある場合は、結合度が高いことを示す設計上の臭いである可能性があります。

Answer 2

テスト対象のクラスを分離するために、必要な数のモックを追加する必要があります。テストの一部であってはならないすべての依存関係のモックが必要です。

簡単にするために、2つまたは3つのクラスをテストにまとめることがあります。これは、それらがコンポーネントのようなものを構築し、高度に結合されているためです。他のすべては嘲笑されるべきです。

私はこの「ベストプラクティス」がモックを1つだけ持っていることを知っており、それも理解していません。単体テストでは、多くのモックがあり、いくつかの環境モックは、私が作成したテストフレームワーク（TransactionService、SecurityService、SessionServiceなど）によってセットアップされます。ギス人がすでに彼の答えで述べたように、考慮すべきことは1つだけです。多くのモックは、依存度が高いことを示しています。それが多すぎる場合を検討するのはあなた次第です。多くの小さなインターフェースがあり、テストで多くのモックを必要とします。

答えを変えるために、次の場合に依存関係をあざけるべきではありません。

• これは、内部クラス、プライベートクラスなどのように、テスト対象のクラスの高度に結合された部分です。
• コレクションなどの一般的な.NETFrameworkクラスです。
• そのクラスとの相互作用を正確にテストする統合テストを作成する必要があります。（他のすべてをモックし、関連するすべてのクラスの単体テストを分離して行います。）
• 特定のクラスをモックするのは高額です。高価すぎると判断する場合は注意が必要です。モックを設定するのは難しいようですが、実際のクラスを使用する場合の保守性の問題と比較すると、簡単です。しかし、インターフェースに対して実装されておらず、モックするのが非常に難しいフレームワークやテクノロジーがいくつかあります。このフレームワーククラスを独自のインターフェイスの背後に配置するにはコストがかかりすぎる場合は、テストでそれらを使用する必要があります。

Answer 3

どの記事を参照しているのかわかりませんが、通常、テスト対象のクラスの依存関係ごとに 1 つのモック オブジェクトがあります。