DAOを使用してデータベースを呼び出すメソッドがあります。
データベースの管理を回避するためにモックメカニズムを使用する必要がありますか(したがって、すべてのDAOメソッドをモックする必要があります)、またはデータベースをメモリにロードして初期化することによってテストするためにdbunit(または同等のもの)を使用する必要がありますか(hsqldbなど)?
これらは各メソッド(モックとdbunit)の長所と短所ですか?
DAOを使用してデータベースを呼び出すメソッドがあります。
データベースの管理を回避するためにモックメカニズムを使用する必要がありますか(したがって、すべてのDAOメソッドをモックする必要があります)、またはデータベースをメモリにロードして初期化することによってテストするためにdbunit(または同等のもの)を使用する必要がありますか(hsqldbなど)?
これらは各メソッド(モックとdbunit)の長所と短所ですか?
データベースをテストします。このコンテキストでモックがどのように意味があるのか わかりません。DAO が機能していることを確認したら、それらを使用するサービスにモックを注入します。
それまでの間、データベースをテストしてください。一時的なテスト データベースを作成するか、すべてのテストをトランザクション対応にすることができます。つまり、テスト作業単位をセットアップし、実行し、検証し、ロールバックします。
モックオブジェクトを使用することをお勧めします。一般に、データベースアクセスは実際にはパフォーマンスが高くなく、多くの時間がかかります。4000 を超えるユニットテストを含むプロジェクトがあり、完全なテストを実行するのに 3 時間以上かかりました。各テストの前後にデータベースにアクセスします。
dbunitに関しては私が使用したので、それが良いかどうかはわかりませんが、単体テストでデータベースへのアクセスを避けると言ったように、ロジックユニットのみに限定する必要があります。
はっきりと答えるのは難しい質問です。ただし、私が提案し、一般的に好んでいるのは、組み込みデータベースまたは外部テスト データベース (統合テストとして) に対して DAO 自体をテストして、DAO が何らかの読み取りデータベースに対して適切に機能することを確認することです。
次に、DAO を使用するコンポーネントの場合は、DAO をモックして、テストでデータベースを明示的に使用する必要がないようにすることができます。
このアプローチの短所は、テスト用にある種の組み込みまたはその他の DB を使用できるようにする必要があることです。
DAO 単体テストをモックできます。ただし、モッキングがDBが提供するものを真に表現するものになるかどうかは完全にはわかりません.
お役に立てれば。