全体的な統合テストの実行時間を延ばそうとしています。現在、さまざまなインメモリ データベース ソリューションを評価しています。アイデアは、実際の DB にヒットするのではなく、テスト中に DAO がメモリ内の db にヒットするようにすることです。これは永続化のために Hibernate を使用する Java アプリです。
H2、Derby、HSQLDB、Oracle Berkeley DB のいずれかの製品を使用した経験をお聞かせいただければ幸いです。
私の懸念のいくつかは次のとおりです: インメモリ DB はストアド プロシージャ、カスタム ネイティブ SQL を実行できますか? 実際の DB とメモリ DB のどちらをヒットするサービスを選択できますか?
そして全体として、このアプローチにはDBブートストラップ（データを含むすべてのテーブルを事前にロード/事前作成する）が含まれているため、DAOレイヤーをモックアウトするだけで、 mem DB で...
ありがとう。
mem db で Oracle Times Ten を見つけました。 http://www.oracle.com/technology/products/timesten/index.html
これは、おそらく最も痛みのない解決策のように思えるかもしれません。追加のモック/構成は必要ないため。DB にヒットするすべての統合テストはそのまま残りますが、データはより高速に配信されます。皆さんはどう思いますか ？
DAO レイヤーをモックアウトします。
些細なSQLを使用しているだけでない限り、一部の主張にもかかわらず、データベース間の微妙な実装の違いと異なる機能セットにより、実行できること（ストアドプロシージャ、ビューなど）が制限され、テストがある程度無効になります。
私が選んだモッキング フレームワークは Mockito です。しかし、その仕事をするものはたくさんあり、DAO を嘲笑することは標準的な方法であるため、多くのドキュメントを見つけることができます。
単体テスト用と本番用に異なるデータベースを使用するのはお勧めできません。
ところで、実際のデータベースでのテストは高速である必要があります。おそらく、テストで何か間違ったことをしているでしょう。