15

トランザクションをロールバックせずに、すべてのテスト ケースの後にデータベースをクリーンアップしたいと考えています。DBUnit のDatabaseOperation.DELETE_ALLを試しましたが、削除が外部キー制約に違反している場合は機能しません。外部キーのチェックを無効にできることはわかっていますが、それによってテストのチェックも無効になります (これを防止したい)。

JUnit 4、JPA 2.0 (Eclipselink)、および Derby のメモリー内データベースを使用しています。何か案は？

ありがとう、テオ

4

8 に答える 8

5

シンプル：各テストの前に新しいトランザクションを開始し、テスト後にロールバックします。それはあなたが以前持っていたのと同じデータベースをあなたに与えるでしょう。

テストによって新しいトランザクションが作成されないことを確認してください。代わりに、既存のものを再利用してください。

于 2011-07-20T14:58:01.843 に答える
2

DBUnit はすべてのテストの前にデータベースを既知の状態に再初期化するため、少し混乱しています。

また、テスト後にデータをクリーンアップしたり変更したりしないことをベスト プラクティスとして推奨しています。

したがって、次のテストのためにデータベースを準備するのがクリーンアップである場合、私は気にしません。

于 2010-10-13T16:32:30.437 に答える
2

はい、トランザクション内テストはあなたの人生をはるかに楽にしてくれますが、トランザクションがあなたのものであれば、クリーンアップ中に補正トランザクションを実装する必要があります ( で@After)。面倒に聞こえるかもしれませんが、適切にアプローチすれば、テスト中に蓄積されたデータを補正 (クリーンアップ) する一連のヘルパー メソッド (テスト内) になる可能性があり@Beforeます (JPA またはストレート JDBC を使用 - 意味のあるものは何でも)。

たとえば、JPA を使用し、テスト中にエンティティで create メソッドを呼び出す場合、すべてのテストで次のパターンを利用できます (好きな場合は AOP を使用するか、単にヘルパー テスト メソッドを使用します)。

  1. テスト中に作成されたすべてのエンティティの追跡 ID
  2. 作成された順にそれらを蓄積します
  3. これらのエンティティのエンティティ削除を逆の順序で再生@After
于 2010-10-13T20:56:37.170 に答える
0

私のセットアップは非常に似ています。Derby（組み込み）+ OpenJPA 1.2.2+DBUnitです。現在のタスクの統合テストを処理する方法は次のとおりです。すべての@Beforeメソッドで3つのスクリプトを実行します。

  1. ドロップDB—すべてのテーブルをドロップするSQLスクリプト。
  2. DBの作成—それらを再作成するSQLスクリプト。
  3. データを取り込むためのテスト固有のDBユニットXMLスクリプト。

私のデータベースには12個のテーブルしかなく、テストデータセットもそれほど大きくはありません—約50レコードです。各スクリプトの実行には約500ミリ秒かかり、テーブルが追加または変更されたときに手動で保守します。

このアプローチは、大きなデータベースのテストにはおそらくお勧めできません。また、小さなデータベースにとっては良い習慣とは言えないかもしれません。ただし、@Afterメソッドでトランザクションをロールバックするよりも重要な利点が1つあります。それは、コミット時に何が発生するかを実際に検出できることです（デタッチされたエンティティの永続化やオプティミスティックロック例外など）。

于 2011-07-20T14:29:51.967 に答える
0

実行するたびに DB ファイルを削除します。

boolean deleted = Files.deleteIfExists(Paths.get("pathToDbFile"));

少し汚れていますが、私にとってはうまくいきます。よろしく

于 2020-04-06T13:48:35.897 に答える