リポジトリパターンに基づいてドメインモデルを開発していますが、TDDの一部としてのすべての単体テストがテストリポジトリに対して実行されています。
私の質問は、SQLバージョンのリポジトリに対して統合テストを作成するのはどの時点ですか？
私の懸念は、オブジェクト（テストリポジトリ）からデータにアクセスするためのコードが正常に機能することです。しかし、データベースのバージョン（SQLリポジトリ）は内部で非常に異なるため、SQLリポジトリ内の重要なコードは機能せず、それ自体はテストされません。意図したとおりに機能していることを確認するにはどうすればよいですか？プロセスについて何かが足りませんか？
よろしく。
リポジトリをモックアウトするテストが必要です（あなたがそうしているように見えます）。それはデータベース自体をクエリしませんが、それらが行ったかのように結果を返します。これらは、リポジトリ関数を呼び出す関数のテストです。
ただし、データベース自体をチェックし、必要なものが返されるかどうかをチェックするテストを行うことも有用であり、推奨されます。それらは、他のものに依存するのではなく、「ユニットテスト」でもあるはずです。データベースが決定された状態にあることに依存しないようにしてください。代わりに、データベースの初期状態を構築するように設定してください。おそらく低速であり、すべてのコミットとビルドで実行されるとは限りません（つまり、実行しないでください）。本当に時間がかかる場合）。
最後に、統合テストでは、実行する必要のあるすべてのことを実行します。
私の意見では、テスト対象のユニットが依存する対応するデータベースコードができたらすぐに、実際のリポジトリを使用する統合テストを追加します。偽造やスタブ化を行うと、単体テストが容易になり、外部の依存関係にイライラしたり正しく設定したりすることなく、コードの特定の側面に集中できます。ただし、結局のところ、スタブ、偽物、モックを含む製品を出荷することはありません。出荷された製品には、すべてが連携する必要のある実際の依存関係とコンポーネントがあります。したがって、テストを実行するときは常に、アプリケーションの一部が連携して動作しているかどうかを知る必要があります。アプリケーションの一部がデータベースへの変更を永続化できない場合は、できるだけ早くそれを知りたいと思います。したがって、外部依存関係の場合、あなたの場合はデータベース、
統合テストの実行には、通常、単体テストよりも時間がかかることに注意してください。そのため、CIビルド中に単体テストのみを実行することをお勧めします。そうすることで、ビルドとコードベースの状態に関するフィードバックをより迅速に得ることができます。ただし、コードが実際にどのように機能しているかを知るために、ナイトリービルドに統合テストを含める必要があります。