データ駆動型ユニットテスト

Question

データベースのデータに依存するAPIをテストするためのベストプラクティスは何ですか？ 「継続的インテグレーション」で注意する必要がある問題は何ですか？ビルドプロセスの一部として単体テストを実行する環境ですか？ビルドスクリプトの一部としてデータベースを展開する（インストーラーを実行する場合があります）か、ハードコーディングされたデータを使用する必要があります[XMLでMSTestデータドリブンユニットテストを使用]

ビジネスロジックレイヤーのデータレイヤーをモックできることは理解していますが、DALのSQLステートメントに問題がある場合はどうなりますか？データベースにアクセスする必要がありますか？

まあ...それは質問の急流です：）...考え？

Answer 1

可能な限りデータベースにアクセスしないようにコードをモックアウトする必要がありますが、SQLをどこかでテストする必要があることは正しいようです。データベースにヒットするテストを作成する場合、頭痛の種を回避するための重要なヒントの1つは、既に適切なデータが利用可能であることに依存するのではなく、セットアップがデータを既知の状態にすることです。

そしてもちろん、ライブデータベースに対してテストしないでください！しかし、それは言うまでもありません：）

Answer 2

前述のとおり、テストとデータを際限なくいじりたくない限り、モックを使用して単体テストでDB呼び出しをシミュレートします。 SQLステートメントのテストは、統合テストの詳細を意味します。単体テストとは別に実行します。2つの異なる獣です。

Answer 3

テストデータベースを自動的に消去し、データベースに接続する必要のあるすべてのテストで使用されると想定されるテストハーネスデータを入力することをお勧めします。適切な分離のために、各テストの前にデータベースをリセットする必要があります-不良データを入れるテストの失敗は、後続のテストで誤った失敗を引き起こす可能性があり、一貫した結果を得るために特定の順序でテストを実行しなければならない場合、面倒になります。

ツール（ DBUnit 、 DBUnit.NET 、その他）または同じことを行う独自のユーティリティクラスを作成します。

あなたが言ったように、他のレイヤーは実際にデータベースにヒットするクラスから十分に分離する必要があるため、テストに関与するあらゆる種類のデータベースの必要性は、コードベースの小さなサブセットを実行するテストに限定されます。コンポーネントにアクセスするデータベースは、それらに依存するすべてのものに対してモック/スタブ化できます。

Answer 4

私がやったことの1つは、既知の状態のテストデータを返す静的メソッドを作成することでした。次に、「偽物」を使用します。実際にデータベースを呼び出しているかのように、このデータを返すDAL。 sql /ストアドプロシージャのテストについては、SQL Management Studioを使用してテストしました。 YMMV！