私は、Hibernate/SQL上に構築された自分のアプリケーション用のAPIをコーディングしています。私はテスト環境とライブ環境の両方にmysqlを使用しています。Junitテスト用データベース
テストのために、私はデータベース、ユーザー、および権限を持っています。だからテストするたびに、私はこれらのステップに従わなければならない：
私のテストでは、mysql dbにガーベジが集まらないようにしたいので、毎回テーブルを削除する必要はありません。この目的のために使用できるいくつかのメモリ内のrdbmsがありますか？また、実行環境に応じてこれとmysqlのどちらを選択するかは、テストまたはライブ用です。
私は、H2、dbUnit、スプリングテストを使用することをお勧めします。 HsqldbとDerbyは合理的な選択肢である他のメモリ内のデータベースです。春のテストでは、独自のデータソースを使用して独自のコンテキストを使用しますが、テストコンテキストの設定は通常のアプリケーションコンテキストの値よりも優先されます。そうすれば、データベース間の切り替えに余計な労力がかからず、アプリケーションがmysqlを使用している間にテストをセットアップしてH2を使用することができます。
mysqlは許容されるSQLに対して許容されていることに注意してください。他のデータベースはより厳しい傾向にあります。ネイティブSQLを使用すると、インメモリ・データベースを使用する際に障害になる可能性があります。
特に、Hibernateを使用しているときにデータレイヤーをテストするのに有益だと思います。複雑なので、実際にやっているべきことを確認したいと思っています。
HSQLDBとH2私はかなり一般的な選択肢だと思います。
個人的に私はもうこのルートを辿ることはありません。単体テストを実行しているときにメモリ内のリストに書き込んだり、読み込んだりするために、テストダブルでDAOをスタブします。複雑な技術はありません。 DBへの実際の永続性がテストされていないことを意味します。私が必要と感じる場合、私は一般的に物理的なDBに具体的に接続するためにDAO自身の単体テストを作成し、それらのテスト。
私はこれらのDAOテストを時々実行していますが、通常は単体テストでデータベースアクセスをテストしています。これらのカスケードをメモリー内ではなく実際のデータベースにします。そのようにして、テーブルメタデータをテストするのは、それらにアクセスするコードだけでなく、正しいものです。しかし、DAOにアクセスする他の層のコードのテストでは、それは私が通常スタブしたり、それらを落とさせるのではなく模倣するときです。 –
@Jim：ありがとう、私はあなたの意見を誤解していないように編集しました –