自動化された統合テストを追加したい既存のアプリケーションがあります。これは、すべてのデータ アクセスがストアド プロシージャによって管理される .Net/SQL Server アプリケーションです。ストアド プロシージャには、ビジネス ロジックが含まれる場合と含まれない場合があります。テスト ベースを構築するのに最も効率的なのは、バグが報告され解決されたときにバグのテストを追加することです。そのため、各テストは、複数のデータベースの複数のテーブルに分散している可能性のある非常に特定のデータ セットに依存します。データベースが小さい場合は、テストを実行する前に各テストのテスト データを含むデータベースのコピーをスピンアップし、テストの終了後にデータベースを削除するだけで済みます。ただし、全体として、これらのデータベースは大きすぎて、毎回全体をコピーして保存することはできません。各テストで実際に使用されるデータのサブセットは管理可能です。全部で 8 つのデータベースがあります。最小は 200 MB、最大は 10 GB で、残りの 6 個はその中間です。
適切なサブセットを取得することが、このプロセスの鍵と思われます。私は SSIS の経験はあまりありませんが、テストに必要なデータのサブセットをパッケージ化する定義済みのパッケージを作成できると確信しています。このアプローチの問題点は、アプリケーションがさまざまな機能領域をカバーしており、特定のテストに必要なすべてのシナリオをカバーするパッケージを構築するのは困難に思えることです。
(表面的には) 理想的と思われる別のオプションは、ストアド プロシージャによって使用されるすべてのデータを記録できるログ フレームワークを作成することです (一部のストアド プロシージャには、複数のテーブルからの複数の選択ステートメントがあります)。したがって、テスト ケースのデータを作成する準備が整ったら、ログ記録を有効にして、データベースの完全なセットに対してテスト ロジックを実行するだけです。次に、すべてのデータベース/テーブルで実行中にアクセスされたレコードのログを取得し、ログからテスト固有の小さなデータベースを作成します。このログは実際のデータである場合もあれば、実際のデータを取得するために使用する一連の select ステートメントである場合もあります。これは高すぎますか？
この状況に対処する方法についてのアドバイスは役に立ちます。