EF4.1 DbSetとEF4 ObjectContextとユニットテスト

Question

私は現在EF4で始まったプロジェクトを持っています。モデル（データベース）の最初のコンテキストにEF4 POCO T4 templatesを使用しています。私は、私のDACロジックに汎用リポジトリを使用しており、永続性のための作業パターンの単位を使用しています。

しかし、ObjectContext/ObjectSetをモックアップする方法を理解しているいくつかの問題が発生しています。私はthis articleのFakeObjectSet<T>サンプルを使用して調べましたが、自動増分IDやトランザクションロールバックなど、いくつかのことが残っています。

私はまだ完全にユニットテスト可能な良いEFデザインを探しています。

私の質問は、EF4.1 DbSetはEF4のユニットテストで多くの問題を解決していますか？完全にテスト可能なEF4.1ソリューションを設計するための優れた包括的な記事はありますか？

また、私はモデルファーストソリューションが必要です。

ありがとうございます。

Answer 1

模擬レイヤの動作を完全にシミュレートすることは、単体テストのポイントではありません。単体テストのポイントは、嘲笑されたレイヤーが単純に機能すると信じています。単体テストは、テストされたメソッドをモックではなく検証します。モックの正しいメソッドが呼び出されたことを確認し、ビジネスロジックがいくつかの値を期待している場合は、渡されたデータを修正するためのコールバックをいくつか設定することになります。例：

データベースにレコードを挿入し、挿入後にエンティティとそのIDを使用するビジネスメソッドがあります。 - あなたは、いくつかの値にIDを設定し、それを使用するAddObjectのコールバックを定義することができ、検証

に予想されるインスタンスを設定することができます

• AddObjectは一度だけ呼び出されたことをセット期待：IObjectSetモックをするように設定されます後のテストで

DbSetは、任意の違いをすることはありません - それだけで同様の行動を周りObjectSetラッパーです。私の意見では、モックを実際のEFとして動作させる効率的な方法はありません。 EF +データベースをシミュレートするモックを作成するために必要な労力は、アプリケーション全体の労力をはるかに大きくします！それはもはや偽のEFプロバイダーになるでしょう。

EFコード（マッピング、クエリ、永続化）とデータベースの動作（自動インクリメント、トランザクションなど）をテストする場合は、統合テストを作成する必要があります。多くの意味を作ったあなたの応答のための

• ASP.NET MVC3 and Entity Framework Code first architecture
• Organizationally, where should I put common queries when using Entity Framework Code First?