LINQ to SQL：多対多の関係を持つ偽のリポジトリ？

Question

私はテーブルClientAdministratorsによって多対多の関係でリンクされているClientsとAdministratorsの2つのテーブルを持っています。

実際のアプリケーションでは、これは正常に動作し、クライアントの管理者のリストを取得できます。私の問題は、リポジトリからこれを取得しているサービスクラスを単体テストしようとしています。

私は自分のリポジトリインタフェースを実装しているFakeRepositoryクラスを持っています。私は、問い合わせるサービスクラスのオブジェクトの内部リストをいくつか持っています。

私の問題は、この多対多関係に対して正常にクエリを実行できるようにするために、偽のクラスで関係を取得する方法を見つけることができないことです。

Dim clients = From c in _repository.GetAllClients _ 
       Select New ClientBizObj With {.ID = c.ID, _ 
              .ClientName = c.ClientName, _ 
              .Admins = (From a in c.ClientAdministrators _ 
                 Select a.Administrator.UserName).ToList} 

c.ClientAdministratorsは（ClientAdministratorの）EntitySetであることがわかります。

私のFakeRepositoryクラスでこの関係を偽って、NullReferenceExceptionsのスローを止めるにはどうしたらいいですか？

私はAdminsを返さない場合は気にしません。クライアントオブジェクトが正常に返されるようにするだけです。

Answer 1

例では、具体的にはデータベース操作ではなく、データアクセス層をモックしようとしています。これは永続性の懸念からロジックを分離するための単体テストではまったく正当です。

説明した問題は、Clientsクラスのモックを作成することで解決できます。このモックでは、ClientAdministratorsプロパティをオーバーライドして、空のコレクションを返しますが、他のすべてを実際のクラスに委譲できます。実際のClientsクラスではなく、あなたの模擬テストを返すためにFakeRepositoryクラスが必要になります。

これを簡単にするためのいくつかの模擬ツールがあります。これらの中で、最も使いやすいものの1つ（と起動するオープンソース）はmoqです。 moqを使用すると、テストのためにすべてのデータアクセスレイヤをモックアウトできるので、独自のFakeRepositoryクラスを構築する必要はありません。

Answer 2

Roy Osherove（TypeMockのチーフアーキテクトと書籍「The Art of Unit Testing」の著者）は、データベース操作を嘲笑しないことをお勧めします。彼はそのようなテストがrelegated to the integration testsであり、実際のデータベースがこのようなテストに関与することを推奨しています。

Answer 3

あなたは他の言葉であなたは、次の操作を実行して、UI、 をモックすることができ、DBをモックしない偽のDBへのDevマジックフェイクを使用することができます。

[HttpPost] 
public ActionResult Create(Client model) 
{ 
    var repository = new FakeRepository<Client>(); 
    repository.Save(model) 

詳細についてはCodePlexの

にDevMagicFakeを見ます

devmagicfake.codeplex.com

おかげ

M.Radwan