2

私はさまざまなビデオを見たり、リポジトリの単体テストに関するさまざまなブログを読んだりしています。

最も一般的なパターンは、本物と同じインターフェースを実装する偽のリポジトリを作成することです。次に、偽物は内部辞書または何かを使用します。

したがって、実際には、本番環境には決して入らない偽のリポジトリのロジックを単体テストしています。

これで、依存性注入を使用して、IDBContext インターフェイスを使用してモック DBContext を注入できます。ただし、実際にはdbcontext（モックされている）に転送する各リポジトリメソッドをテストしているだけです。

各リポジトリ メソッドが dbcontext を呼び出す前に多くのロジックを持っていない限り、それは少し無意味に思えますか?

テストを統合テストとしてリポジトリに置いて、実際にデータベースにヒットさせる方が良いと思いますか?

新しい EF 4.1 では、テスト プロジェクトの接続文字列に基づいてオンザフライでデータベースを作成できるため、これが簡単になり、dbcontext.Database メソッドを使用してテストを実行した後にデータベースを削除できます。

4

2 に答える 2

4

あなたの反論は部分的に正しいです。それらの正確さは、リポジトリがどのように定義されているかによって異なります。

  • 最初のリポジトリの偽造またはモックは、リポジトリ自体をテストするためではなく、リポジトリを使用してレイヤーをテストするためのものです。
  • リポジトリが公開さIQueryableれ、上位層が linq-to-entities クエリを構築できる場合、リポジトリをモックすることは、存在しないロジックをテストすることを意味します。統合テストが必要で、実際のテスト データベースに対してクエリを実行します。テストごとにデータベースを再デプロイして非常に遅くするか、トランザクションで各テストを実行し、テストが完了したらロールバックすることができます。
  • リポジトリが公開されていない場合IQueryableでも、それをブラック ボックスと見なしてモックすることができます。クエリ ロジックはリポジトリ内にあり、統合テストで個別にテストされます。

リポジトリ自体とテストに関する一連の他の回答を参照してください。

于 2011-07-01T13:06:52.153 に答える
0

私が見た最良のアプローチは、NHibernate マッピング情報に基づいて TestFixtureSetup で作成された SQLLite データベースを使用する Sharp Architecture からのものです。

その後、リポジトリ テストはこのインメモリ データベースを使用します。

技術的には、データベースが関係するため、これはまだ統合テストですが、実際には、単体テストのすべてのボックスにチェックを入れています。

1) データベースは一時的です - 接続文字列の設定を気にする必要はありません。また、ユニット テストで使用するサーバーのどこかに完全なデータベースを配置する必要もありません。

2）セットアップは高速で、テストはすべてメモリ内で行われます。

3) NHibernate マッピング情報を使用してスキーマを生成するため、単体テストのセットアップをコードの変更と同期させることを心配する必要はありません。

http://wiki.sharparchitecture.net/default.aspx?AspxAutoDetectCookieSupport=1

EF でも同じアプローチを使用できる可能性があります。

于 2011-07-01T12:36:35.023 に答える