前提: SQL Server 2005 に対して .NET コーディングを使用
ほとんどの人が、データベースに影響を与える単体テストに状態をどのように組み込むのか疑問に思っていました。いつ、どこでモッキングを使用するかはわかっていますが、それを超えて実際にデータベース テストを実行したい場合は、データベースのセットアップと破棄にどのような戦略を使用しますか? テストごとにこれを行いますか？または、データベースで特定のシナリオをセットアップし、その「世界の状態」に対していくつかのテストを実行します。どんなアドバイスも役に立ちます。ありがとう。
ほとんどのテストケースを空のデータベースに対して実行しました。つまり、データベース スキーマのみが存在し、データは存在しません。実際のデータは、必要に応じて、テスト ケースまたはセットアップとティアダウンによって作成および削除されます。これは、準備されたデータベースを持つよりも時間がかかりますが、データベース スキーマの変更に対してより耐性があります。
まず、すべてのデータベースDDLの「スクリプト」はC＃クラスで記述されています。私はこれを行うためにMigrator.NETを使用しています。すべてのクラスにDBをアップグレードまたはダウングレードするためのロジックが含まれているいくつかのクラスがあります。
DBアクセスが必要なユニットテストを実行するために使用する「projectname_test」というデータベースがあります。このDBは、Migrator.NETクラスによってアップグレードされています。このDBは、CIプロセス（CC.NET）によってアップグレードされます。
そのDBにアクセスする単体テストは、実行後にそのDBにあるすべてのものを削除します。そして、それを大幅にプレイしたい場合は、テストDBをドロップするだけです。CC.NETプロセスによって再構築されます。:)
これが私が NUnit で行うことです... [Setup] 属性でマークされたメソッドでデータベース トランザクションを開始します。必要に応じてデータベースの状態をセットアップします。次に、NUnit はその状態に対してテストを実行します。[TearDown] 属性でマークされたメソッドでデータベース トランザクションをロールバックします。そのようにデータベースの状態を変更することはありません。
この質問と回答を見てください 。NUnitを使用してデータベース関連のコードをテストするにはどうすればよいですか。
NHibernateをORMとして使用する場合、実際のSQL Serverデータベース（app.configの数行）を、テストごとに簡単に再作成できるインメモリSQLiteデータベースと簡単に交換できます。このようにして、単体テストを実行する統合/ビルドサーバーがSQLServerにアクセスする必要がなくなります。