nhibernateをサポートするリポジトリパターンとしてデータアクセスレイヤーを設計したとしましょう。統合テストの目的は何ですか？
私は不思議です。リポジトリをテストしているうちに、実際にテストしているものは何ですか？
私たちはテストしていますか？Ormはそれが正しいのですか、またはデータベースが期待どおりにクエリを実行できますか？
私のようなリポジトリがある場合は、 OrderRepository、どうして私はSave、Update、FindbyIdメソッドをテストすべきですか？
私がテストする必要があるのは、Ormマッピングですが、他のものは私には意味がないと思います。
NhibernateのようなOrmsのため、Entity Frameworkは成熟したフレームワークなので、どうして私は "context.Add（）"または "session.Save（）"が正しく動作するかどうかを心配する必要がありますか？
実際には、その投資が戻ってこない（またはごくわずかな）可能性があります。テストは時々そうです。
これは、テストの値をどのように定義するかによって異なります。一部の人にとっては、100％のカバレッジを追跡することに固有の価値があります。これらのテストを構築する時間があれば、素晴らしい。 100％のカバレッジは、暖かいファジーなものです。しかし、あなたが示唆するように、そこに1つ持って来たテストのすべてが本当に意味があるわけではありません。その場合のプライマリ値は、しばしば100％カバレッジメトリックの自慢の権利です。
おそらく、統合テストは、ORMやDALを構築するために使用することができる他のツールのコンテキスト外の貴重なツールとして立つかもしれません（おそらく、厄介な顧客はレポートのどこかの番号を見たいと思っています）。 。テクニカルではなく非開発者リソースの観点からDALをブラックボックスとみなす場合は、のDALインターフェイスの実装をテストし、実装が正常に動作することを保証するツールが必要な場合がありますライブ環境で正しく構成されているかどうかを確認します。
おそらく統合テスト全体が実際にコードのテストではないかもしれませんが、データベースとアプリケーションが相互に適切に構成されてお互いに対話しているかどうかという観点から見ています。 その人はORMやマッピングについて気にしませんが、UMLダイアグラム上の2つの別々のシステムコンポーネントが、システムの仕様の範囲内で一緒に働いていることに気付きます。そのコンポーネントがORMを使用するのか、手動SQLを使用するのか、または魔法のpixieダストを使用しても、そのテストと違いはありません。
チームのどの役割がテストを望んでいるのか、実際にテスト/検証しようとしていることが本当に分かります。