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

Question

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

Answer 1

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

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

モックを 1 つだけ使用するという「ベスト プラクティス」はわかっていますが、理解していません。単体テストには多くのモックがあり、いくつかの環境モックは私が作成したテスト フレームワークによってセットアップされています (例:TransactionService、SecurityService、SessionService)。考慮すべきことは 1 つだけです。Gishu の回答ですでに述べたように、多くのモックは高い依存性を示しています。それが多すぎる場合は、それを考えるのはあなた次第です。小さなインターフェイスが多数あるため、テストでは多数のモックが必要になります。

答えを変えるには、次のようにする必要があります ない 次の場合に依存関係をモックします。

• これは、内部クラス、プライベート クラスなどのように、テスト対象のクラスの高度に結合された部分です。
• Collection などの一般的な .NET Framework クラスです。
• そのクラスとの対話を正確にテストするための統合テストを作成したいと考えています。(他のものはすべてモックしており、関与するすべてのクラスの単体テストは依然として分離されています。)
• 特定のクラスをモックするにはコストがかかりすぎます。モックはセットアップが難しそうに見えますが、実際のクラスを使用する場合に発生する保守性の問題に比べれば簡単であることがわかります。ただし、インターフェイスに対して実装されておらず、モックするのが非常に難しいフレームワークやテクノロジがいくつかあります。このフレームワーク クラスを独自のインターフェイスの背後に配置するのが高価すぎる場合は、テスト内でこれらのクラスを使用する必要があります。

Answer 2

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

しかし、「記事」が示唆しているのは次のようなことだと思います。

• の予防 過度の嘲笑. 。単体テストですべての共同作業者を模擬する場合、ドアを開けたままにすることになります。実際の協力者を代用すると、シナリオが失敗する可能性があります。モックの数を最小限に抑え、可能な限り実際の協力者を使用することで、そのリスクを最小限に抑えることができます。
• ハイカップリング アラート:単体テストを作成するために多くの共同作業者をモックする必要がある場合、それはカップリングが高いことを示すデザインの匂いである可能性があります。

Answer 3

私は、あなたが参照しているものの記事わからないんだけど、私は通常、テスト対象のクラスの依存関係ごとにモックオブジェクトを持っています。