エンティティ フレームワークのユニット/統合テストに関する多くの SO リンクを読みましたが、誤解していない場合はすべて要約します。
リポジトリ インターフェイスが IQueryable を公開する場合、統合テストを実行する必要があります (単体テストでは不十分です)。これは、エンティティへの linq である IQueryable をオブジェクト クエリへの linq に変えることができるためです。データベース。
リポジトリ インターフェイスが IEnumerable または List のみを公開する場合は、リポジトリの単体テストで十分です。
多くの新しいインターフェイス メソッドを追加せずに、自分のサービスで IQueryable を作成するのは非常に優れていることはわかっています...
しかし、上記が当てはまり、可能であれば統合テストを避けたい場合...
どう思いますか？
リポジトリ インターフェイスが IEnumerable または List のみを公開する場合は、リポジトリの単体テストで十分です。
いいえ、それは誤解です。リポジトリが公開されているIEnumerable場合、またはListそれを偽造またはモックし、リポジトリを使用してロジックを単体テストしても安全な場合。リポジトリ自体は、実際のデータベースに対してテストする必要があるデータベース クエリを定義するため、統合テストでカバーする必要があります。
クエリをリポジトリの背後に隠す主な理由は、関心を分離し、アプリケーション ロジックとデータベースで実行されるロジック (クエリ) の間に厳密な境界を定義することです。各ロジックには独自のテストが必要です。
あなたが参照している質問は、おそらくEFコンテキスト/ EFセットのモックまたは偽造、またはリポジトリの公開について議論したものですIQueryable。このような場合、リポジトリはデータベースで実行されたロジックを上位層に公開し、正しいテストをより困難にします。このような場合、アプリケーション ロジックの単体テストを行い、Linq-to-objects を使用して何らかの方法で Linq-to-entities (データベース ロジック) を偽造する必要があります。しかし、そのようなテストはそれらのクエリをテストするには十分ではないため、単体テストの一部を複製する統合テストも必要です。