私のソリューションでは、データベースに依存せず、データベースのような外部依存関係を持つモックと統合テストがあります。オブジェクトにLINQを使用する単体テストのLINQにエンティティの動作を複製する
モックを使用して単体テストを実行するとき、LINQ to Objectが使用されます。統合テストまたは実際のプログラムが実行されると、LINQ to Entitiesが使用され、LINQ to Objectよりも厳密です。
ユニットテストでLINQ To Objectをより厳密に再現する方法はありますか？
ユニットのテストロジックがEFで提供されたIQueryableで動作したら、単体テストでEFを模擬してテストすることはできません。それは常にlinqからエンティティへのlinqからオブジェクトへの切り替えにつながります。何かが単純化されている場合は、単体テストでこれを処理する正しい方法は、模擬の代わりに偽物を書くことです。偽は依存関係の動作をシミュレートします。この場合、偽物を書くことは、実際のプロバイダがデータベースで動作するのとまったく同じ方法で、インメモリコレクションで作業するEFプロバイダを書くことを意味します。そのようなプロバイダを書くことはおそらくプロジェクトそのものです。
ロジックにlinq-to-entitiesクエリが含まれていると、インテグレーションテストでそれをテストするか、またはコードをリファクタリングしてクエリ自体が別のメソッド（統合テストでテスト済み）になり、元のロジックが依存するようにする必要があります。代わりにEF自体にメソッドを含むクラス - これはIQueryalbeが公開されていないリポジトリパターンにつながりますが、リポジトリはいくつかのエンティティで動作する必要なクエリごとにメソッドを公開します。私は個人的にこの種のリポジトリが嫌いです。 Here is recent discussionについて、異なるリポジトリ実装について説明します。
データベースをメモリ内に変更する統合テストを使用する場合は、EFv4.1とコードでまず接続文字列をSQL Compact 4に変更するだけで、可能です（特殊な直接SQL呼び出しまたはマッピングでいくつかの特別なSQLタイプを要求する）。 EDMXファイルのEFの場合、EDMXファイルは厳密なデータベースバージョンと緊密に結合されているため、動作しません。単体テスト用の特別なEDMXは、別のコードを再度テストするため、オプションではありません。
Here is set of related questionsは、EFコードとリポジトリのユニットテストに関する課題について議論しています。
IRepositoryインターフェイスを定義するためにリポジトリパターンを使用できます。実際のコードでは、Entity Frameworkを使用して実装することができます。単体テストでは、模擬フレームワークを使用してテスト用オブジェクトを返します。
データベースと会話するレイヤーの単体テストに本物の価値と本番コードのようなすべての動作を持たせたい場合は、データベースと話をする必要があります。単体テストに依存しないというルールを破っていると見なされるかもしれませんが、というデータベースと話すよりも、LINQをエンティティに任せることは他にありません。それはメモリ内のデータベースである可能性があります（おそらくそうでなければなりません）。例えばhow is Ayende doing itを参照してください。