単体テストで、なぜリポジトリを2回作成するのですか？

先日、ユニットテストについて少し読んでいて、人々がリポジトリインターフェイス（つまりIExampleRepository）を作成してから、実際のリポジトリ（public class ExampleRepository : IExampleRepository）とユニットテストに使用するリポジトリ（）を作成する例をいくつか見ましたFakeExampleRepository : IExampleRepository。

IExampleRepositoryそれらはと同じ方法を実施したExampleRepositoryが、異なるLINQクエリと、。

ここの目的は何ですか？コードの単体テストの一部は、メソッドが正しく機能することを確認することだと思いましたか？しかし、「実際の」クエリとテスト内のクエリの2つのまったく異なるクエリを使用すると、テストはどの程度意味がありますか？

単体テストの目的の1つは、一度に1つだけテストすることです。つまり、単一のクラスとメソッドです。リポジトリ自体がテスト中でない場合は、通常、メソッド/クラスのロジックをテストするために、何らかの方法でこれをモックアウトします。

つまり、「実際の」リポジトリ*でもテストする必要がありますが、これは通常、統合/システムテストで行われます。

* _{テスト用に設定されたリポジトリのように、明らかに本物です。たぶん、たとえば本番DBではありません。}

私はjkからの2つの答えに同意します。とヤン・ヒューデック-彼らはいくつかの本当に良い情報を提供します。でも少し追加したいと思いました。

最初の質問（「ここでの目的は何ですか？」）は重要です。あなたが説明している場合、本当の目的はIExampleRepository、リポジトリの実装をテストするのではなく、インターフェースを利用しているクラスをテストすることです。を作成するFakeExampleRepositoryと、実際のリポジトリクラスの詳細を気にすることなく、これらのクライアントクラスをテストできます。

これは、設定しようとしているオブジェクトがテストを困難にする場合（たとえば、ファイルシステムへのアクセス、Webサービスの呼び出し、データベースへの通信など）に特に当てはまります。インターフェース（および他のそのような技法）を使用することにより、カップリングを低く保ちます。したがって、クラスXはインターフェースについてのみ知る必要があり、実装の詳細について知る必要はありません。目標は、クラスXが正しいことを行っていることを確認することです。

モッキング（またはスタブ、偽造...微妙な違いがあります）は、単体テストとTDDのための強力なツールです。しかし、これらの実装を手動で作成して維持するのは面倒です。したがって、ほとんどの言語に役立つモックライブラリがあります。C＃を使用しているので、シンプルで非常に強力なMoqをお勧めします。その後、モック実装用の追加コードを積み上げることなく、インターフェースに対してテストできます。

ここの目的は何ですか？

隔離。

ユニットのアイデアは、可能な限り最小テストするためにそれをテストユニットコードを。これを行うには、テスト内の他のすべての製品コードから分離します。

偽のクラスを作成することで、テスト対象のクラスのみが本番用コードになります。

偽のリポジトリを適切に作成してテストが失敗した場合、問題はテスト対象のコードにあることがわかります。これにより、診断のメリットが無料で得られます。

これらの偽物をすばやく生成してテスト条件を設定し、それらを使用してアサートするための分離フレームワーク（@Allanによって提案されたMoqなど）を見てください。

単体テストにモックインスタンスを提供する理由は3つあります。

1. テストの範囲を制限して、テストが宛先のバグの影響を受けないようにします。おそらく、まだ完了していないか、安定していないか、他の誰かのバグがテストに影響を与えたくないためです。
2. 被扶養者はセットアップが複雑です。たとえば、実際のデータアクセスレイヤーは、実際にテストデータベースをセットアップする必要があるため、モックアウトされることがよくあります。実際のデータアクセスレイヤーをテストする必要がありますが、他のものをデバッグするときにコストのかかるセットアップを制限できます。
3. 依存クラスがさまざまな種類のエラーに適切に反応することをテストするには、あらゆる種類の間違った答えを返すモックバージョンを提供します。多くの故障モードは再現がかなり困難ですが、それでもテストする必要があります。