データベースからのデータに依存する API をテストするためのベスト プラクティスは何ですか? ビルド プロセスの一部として単体テストを実行する "継続的インテグレーション" 環境で注意する必要がある問題は何ですか? つまり、ビルド スクリプトの一部としてデータベースを展開しますか (インストーラーを実行することもできます)、それともハードコードされたデータ [XML を使用した MSTest データ ドリブン ユニット テストを使用] を使用する必要がありますか?
ビジネスロジックレイヤーのデータレイヤーをモックできることは理解していますが、DAL の SQL ステートメントに問題があった場合はどうなりますか? データベースにアクセスする必要がありますよね？
うーん...それは質問の嵐です:)...考えはありますか？
可能な限り、データベースに完全にアクセスしないようにコードをモック化する必要がありますが、どこかで SQL をテストする必要があることについては正しいようです。データベースにヒットするテストを作成する場合、問題を回避するための重要なヒントの 1 つは、適切なデータが既に利用可能であることに依存するのではなく、セットアップでデータが既知の状態になるようにすることです。
もちろん、実際のデータベースに対してテストしないでください。しかし、それは言うまでもありません:)
前述のように、テストとデータを際限なくいじりたくない場合を除き、モッキングを使用して単体テストで DB 呼び出しをシミュレートします。SQL ステートメントのテストは、より多くの統合テストを意味します。単体テストとは別に実行します。これらは 2 つの異なる獣です。
テスト データベースを自動的にワイプし、データベースに接続する必要があるすべてのテストのためにそこにあると想定されるテスト ハーネス データを入力することをお勧めします。適切な分離のために、各テストの前にデータベースをリセットする必要があります。一貫した結果を得るために特定の順序でテストを実行する必要がある場合、悪いデータを入力して失敗したテストは、後続のテストで誤った失敗を引き起こす可能性があります。
ツール（DBUnit、DBUnit.NETなど）を使用してデータベースをクリアしてデータを入力するか、独自のユーティリティ クラスを作成して同じことを行うことができます。
あなたが言ったように、他のレイヤーは実際にデータベースにヒットするクラスから十分に分離する必要があるため、テストに関与するあらゆる種類のデータベースの必要性は、コードベースの小さなサブセットを実行するテストに限定されます。データベースにアクセスするコンポーネントは、それらに依存するすべてのものに対してモック/スタブ化できます。
私が行ったことの 1 つは、既知の状態のテスト データを返す静的メソッドを作成することでした。次に、「偽の」DAL を使用して、実際にデータベースを呼び出しているかのようにこのデータを返します。SQL/ストアド プロシージャのテストに関しては、SQL Management Studio を使用してテストしました。YMMV！