私はリポジトリパターンに基づいてドメインモデルを開発しており、TDDの一部としての私のユニットテストはすべてテストリポジトリに対抗しています。私のSQLRepositoryに対してUnit Testsも実行する必要がありますか？
私の質問は次のとおりです。SQLバージョンのリポジトリに対してどの時点で統合テストを作成しますか？
私の懸念は、オブジェクト（テストリポジトリ）からデータにアクセスするコードが正常に動作することです。しかし、データベース・バージョン（SQL Repository）は、SQL Repository内の私の重要なコードが機能しなくなり、それ自体がテストされないことをカバーしています。意図したとおりに動作するようにするにはどうすればよいですか？私はプロセスについて何か不足していますか？
よろしくお願いいたします。
リポジトリを模倣したように（あなたのように見える）、データベース自体にクエリを実行しないで、結果を返すテストが必要です。これらは、リポジトリ関数を呼び出す関数のテストです。
しかし、データベース自体をチェックし、必要なものを返すかどうかを確認するテストを行うこともお勧めします。彼らはまた、他のものに依存することではなく、 "単体テスト"でなければなりません。データベースが決定された状態にあることに依存しないでください。代わりに、データベースの初期状態を構築するための設定を行います。おそらく遅くなり、すべてのコミットとビルドで実行されない可能性があります（つまり、実行しないでください本当に時間がかかる場合）。
最後に、統合テストでは、すべきことをすべて実行します。
私の意見では、テスト対象のユニットが依存する対応するデータベースコードがあるとすぐに、実際のリポジトリを使用する統合テストも追加します。偽造やスタブを使用すると、単体テストが容易になり、外部依存関係に惑わされず正しく設定されることなく、コードの特定の部分に集中することができます。しかし、一日の終わりには、スタブ、偽物、モックで製品を出荷しているわけではありません。出荷される製品には、すべてが連携しなければならない実際の依存関係とコンポーネントがあります。したがって、テストを実行するたびに、アプリケーションの一部が連携して動作するかどうかを知る必要があります。私のアプリケーションの一部がデータベースに変更を残すことができない場合は、できるだけ早くそれを知りたいと思います。したがって、あなたの外部依存関係データベースが、あるレベルの機能と価値をコードに提供するレベルにある場合は、統合テストスイートを追加してください。
実行中の統合テストは通常、単体テストよりも時間がかかることに注意してください。したがって、CIビルド中に単体テストを実行することができます。そうすれば、ビルドとコードベースの健全性に関するフィードバックをより早く得ることができます。ただし、あなたのコードが実際にどのように動作しているかを知るために、夜間ビルドに統合テストを組み込む必要があります。
ユニットテストは、外部システムには触れません。したがって、SQLRepositoryに対して実行されるテストは統合テストになります。それを超えて、私はこの答えに完全に同意します。 –