この夏、私は基本的な ASP.NET/SQL Server CRUD アプリを開発していましたが、単体テストは要件の 1 つでした。データベースに対してテストしようとしたときに、問題が発生しました。私の理解では、単体テストは次のようにする必要があります。
- ステートレス
- 互いに独立
- 同じ結果で繰り返し可能、つまり永続的な変更がない
これらの要件は、データベース用に開発する場合、互いに矛盾しているように見えます。たとえば、挿入する行がまだそこにないことを確認せずに Insert() をテストすることはできないため、最初に Delete() を呼び出す必要があります。しかし、それらがまだそこにない場合はどうなりますか? 次に、まず Exists() 関数を呼び出す必要があります。
私の最終的な解決策には、非常に大きなセットアップ関数 (ヤッ!) と、最初に実行され、セットアップが問題なく実行されたことを示す空のテスト ケースが含まれていました。これは、テストのステートレス性を維持しながら、テストの独立性を犠牲にしています。
私が見つけた別の解決策は、 Roy Osherove の XtUnit のように、簡単にロールバックできるトランザクションで関数呼び出しをラップすることです。これは機能しますが、別のライブラリ、別の依存関係が含まれており、目前の問題に対する解決策としては少し重すぎるようです。
では、この状況に直面したとき、SO コミュニティは何をしたのでしょうか?
tgmdbm は次のように述べています。
通常、お気に入りの自動単体テスト フレームワークを使用して統合テストを実行します。そのため、混乱する人もいますが、同じルールに従っているわけではありません。多くのクラスの具体的な実装を含めることができます (それらは単体テストされているため)。具象クラスが相互に、およびデータベースとどのように相互作用するかをテストしています。
したがって、これを正しく読んだ場合、データ アクセス層を効果的に単体テストする方法は実際にはありません。または、データ アクセス レイヤーの「単体テスト」には、データベースとの実際のやり取りとは関係なく、クラスによって生成された SQL/コマンドなどのテストが含まれますか?