テスト駆動開発を実践する初心者として、私はしばしば、データベースへの永続性を単体テストする方法について困惑することになります。
技術的にはこれが統合テスト (単体テストではない) になることはわかっていますが、次の最適な戦略を見つけたいと考えています。
これらを行うためのベストプラクティスは何ですか?
SQL のテストについて: これが可能であることは承知していますが、NHibernate のような O/R マッパーを使用すると、出力クエリに使用されるエイリアスにいくつかの名前付けのいぼが付けられます。私はそれをテストすることができました。
すべてを放棄して、単に NHibernate を信頼する必要がありますか? それが賢明かどうかはわかりません。
DBユニットを調べます。これは Java ライブラリですが、C# に相当するものが必要です。データベースの内容を把握できるように一連のデータを使用してデータベースを準備できます。その後、DB Unit と連携してデータベースの内容を確認できます。多くのデータベース システムに対して実行できるため、実際のデータベース セットアップを使用したり、HSQL in Java (メモリ内オプションを使用した Java データベース実装) などを使用したりできます。
コードがデータベースを適切に使用していることをテストしたい場合 (おそらくそうする必要があります)、これは各テストを分離し、データベースが期待されるデータを準備していることを確認する方法です。
Mike Stone が言ったように、DbUnit は、テストを実行する前にデータベースを既知の状態にするのに最適です。テストが完了すると、DbUnit はデータベースをテスト実行前の状態に戻すことができます。
データベース接続をモックアウトして単体テストを行います。このようにして、メソッド呼び出しのフロー内の特定のクエリが成功または失敗するシナリオを構築できます。私は通常、実際のクエリテキストが無視されるようにモックの期待値を作成します。これは、メソッドのフォールトトレランスと、メソッドがそれ自体をどのように処理するかをテストしたいためです。SQLの詳細は、その目的とは無関係です。
明らかに、これは、SQLが間違っている可能性があるため、テストでメソッドが機能することを実際に検証しないことを意味します。ここで統合テストが始まります。そのために、私は自分自身でそれらを理解し始めたばかりなので、他の誰かがより徹底的な答えを持っていることを期待しています。
この正確な問題をカバーするデータ層の単体テストに関する投稿をここに書きました。（恥ずべき）プラグインで申し訳ありませんが、記事が長すぎてここに投稿できません。
お役に立てば幸いです。過去 6 か月間、3 つのアクティブなプロジェクトで非常にうまく機能してきました。
よろしく、
ロブ G
特にORMを使用せずに、データベース（接続）をモックするユニットテストの永続性で私が経験した問題は、クエリが成功したかどうかが本当にわからないことです。クエリが特定のデータベースバージョン用に特別に設計されており、そのバージョンでのみ成功する可能性があります。データベースをモックした場合、それを見つけることはできません。したがって、私の意見では、単体テストの永続性は限られた用途にすぎません。ターゲットデータベースに対して実行されるテストを常に追加する必要があります。
のためNHibernateに、私は間違いなくNHibernate API単体テストのモックアウトを提唱します-ライブラリが正しいことをすることを信頼してください。データが実際にDBに送られることを確認したい場合は、統合テストを実行してください。
JDBC ベースのプロジェクトでは、私の Acolyte フレームワークを使用できます: http://acolyte.eu.org。特定のテスト DB を管理する必要なく、JDBC 抽象化の恩恵を受けて、テストしたいデータ アクセスをモックアップできます。
また、データベースをモックして、クエリが期待どおりであることを確認します。テストが間違ったSQLをチェックするリスクがありますが、これは統合テストで検出されます
技術的には、永続性の単体テストは単体テストではありません。それらは統合テストです。
mbUnitを使用するC＃では、属性SqlRestoreInfoとRollBack属性を使用するだけです。
[TestFixture]
[SqlRestoreInfo(<connectionsting>, <name>,<backupLocation>]
public class Tests
{
[SetUp]
public void Setup()
{
}
[Test]
[RollBack]
public void TEST()
{
//test insert.
}
}
属性名がわずかに異なることを除いて、NUnitでも同じことができます。
チェックに関しては、クエリが成功した場合、通常は2番目のクエリを実行して、データベースが期待どおりに変更されているかどうかを確認する必要があります。
私は通常、リポジトリを作成し、それを使用してエンティティを保存し、新しいエンティティを取得します。次に、取得されたものが保存されたものと等しいと主張します。