問題タブ [fake-repositories]

自宅で開発するときは、TDD と少しの DDD に向けて自分の精神を押し上げようとしています。

私が理解できないことの 1 つは、テスト用に偽のリポジトリを作成する理由です。私はあまり詳しく調べていませんが、テストのアイデアは、コードを切り離し (柔軟性を高める)、必要なコードを削減し、バグの数を減らすことです。

それでは、誰かが偽のリポジトリをテストするのが好きな理由について、私の愚かな頭脳に記入してもらえますか? 実際のデータベースに対してテストすることは、偽のデータベースを作成するよりもはるかに優れた代替手段であると考えていました。なぜなら、それが実際のデータストアに対して機能することがわかっているからです。

ClientsとAdministratorsの2つのテーブルがあり、ClientAdministratorsテーブルによって多対多の関係でリンクされています。

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

リポジトリインターフェイスを実装するFakeRepositoryクラスがあり、サービスクラスがクエリを実行するためのオブジェクトの内部リストがいくつかあります。

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

c.ClientAdministratorsは（ClientAdministratorの）EntitySetであると私に言っています。

FakeRepositoryクラスでこの関係を偽造して、NullReferenceExceptionsのスローを停止するにはどうすればよいですか？

Adminsが返されないかどうかは関係ありません。正常に返されるには、Clientオブジェクトが必要です。

私は次のリポジトリインターフェースを持っています

次に、上記のインターフェイスから継承する次のリポジトリクラスがあります

IRepository<>からも継承するFakeRepository<>を作成しました

リポジトリと偽物の唯一の違いは、LinqToSQL DBContextを使用するのではなく、テスト目的で偽物を作成したことです。

次に、単体テストで実行できることは次のとおりです。

したがって、私のテストは常にメモリ内のfakedbcontextに対して実行されます。

ただし、構造マップエラー104プラグインタイプエラーが発生し、理由がわかりません。