問題タブ [dbunit]

自動テストと dbUnit は初めてです。アドバイスをいただければ幸いです。

次の方法で実行されるテスト スイートを作成します。

• インメモリ H2 データベースを作成する
• DDL スクリプトを実行してテーブルを作成する
• dbUnit を実行して、すべてのテストで使用される初期データ ( STATE0と呼びましょう) を挿入します。
• テストを実行する

そこまでは良さそうに見えますが、理解できないのは、テスト実行後にデータベースをSTATE0に戻し、データを変更するにはどうすればよいですか?

dbUnitでできますか？
それとも何か他のもので？
各テストの前にデータベースを再作成する必要がありますか?

テストでトランザクションを単純にコミットしないことは、私には適切ではありません。テストは最終的に複数のデータベース接続で複数のトランザクションを実行する可能性があるためです。

そのため、データ ソースとして dbUnit で使用している XML ファイルがあり、その中にいくつかの日付が含まれています。ファイルの日付は「2010-02-04」のようになっていますが、ロードされてテストで印刷または比較するためにアクセスすると、日付は「2010-02-03 23:00」と見なされます。

これは EDT/EST に関係していると推測していますが、dbUnit (または休止状態) に正しいタイムゾーンを使用させる方法がわかりません。

dbUnit と日付の経験がある人はいますか?

ありがとう、ピーター

編集
わかりました、何らかの理由で、正しいEDTとして日付を読み取り、それをESTとして保存していますが、これは技術的には正しくありません（ここではEDTです）が、私のコンピューターでは正しいですESTだそうです。この変換により、日付が 1 時間「失われます」。Java が私たちが EST であると考える理由がわかりません (Windows XP は私たちがそうではないことを知っています)、そして dbUnit が日付を EDT にすべきだと考える理由が二重にわかりません。これはかなり紛らわしいです。

EDIT それは問題ではないので、Hibernate XMLを取り出しました。1. dbUnit はソース XML から日付を文字列として読み取り、それを java.sql.Date に変換します。本質的に、これらは時間/分/秒を保存しませんが、ミリ秒を見ると、EDT では真夜中ですが、UTC では午前 4 時であることを示すために、明らかに 4 時間分調整されています。また、これは、「アメリカ/ニューヨーク」または同等のラベルが付けられたタイムゾーンを持つカレンダーによって支えられています。正確には思い出せません。2. この日付を印刷するたびに、EST であると認識している私のシステムは、UTC の午前 4 時を前日の午後 11 時に再変換します。3.例としてテスト用に自分で日付を作成するときはいつでも、それとUTCの違いを作るために5時間分のミリ秒。明らかに、これらは異なる「日付」であり、失敗します。

本当の問題は 2 つあると思います: 1. コンソールが EST だと思うのはなぜですか? 私の知る限り、Windows XP の設定は正しいです。Java 1.4 に誤った TZ を取得する問題があったことは理解していますが、これは修正されており、(おそらく) 1.6 を実行していると思います。2. 同じ JVM 内にある dbUnit が適切なファンシー TZ を使用するのはなぜですか。

日付を一緒に使用するのをやめることもできると思いますが、必ずしもその余裕があるわけではありません。

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

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

ありがとう、テオ

最新バージョン2.4.8でDbUnitを使用していますが、ユニットテストで次のメッセージとともに多くの警告が表示されます。

だから私はこれを追加すると思いました（私はMySQLデータベースを使用しています）：

しかし、これはこれらの警告を回避するのに役立ちません。ここで何が問題になっていますか？

よろしくお願いします。ティム。

以下を使用して、一連の基本キーによって Oracle データベースからデータセットをエクスポートしようとしました。

それは私に45MBのデータファイルをスローします!!!、ファイルをチェックすると、問題は複合キー（6つの外部キー）を持つテーブルへの参照であることがわかりました。一意の参照レジストリをエクスポートするのではなく、テーブルデータ全体が必要でした。これは DBUnit のバグだと思います。このアプローチの解決策を知っている人はいますか?

私は、新しい軽量のデータベース ポピュレーション フレームワークを作成することを考えていました。私は絶対にdbunitが嫌いです。その前に、誰かがすでにそれを行っているかどうかを知りたいです。

dbunit について私が嫌いなこと:

1) 記述して開始するための最も単純な形式は非推奨です。彼らは肥大化したフォーマットを使用することを望んでいます。xml スキーマが必要なものもあります。ええ、何でも。

2）それらは、記述した順序ではなく、xmlファイルでテーブルが定義されている順序で行にデータを入力します。外部キー制約が問題を引き起こさないようにデータを並べ替えることができないため、これは非常に悪いことです。これは、それらを完全にオフにするという面倒なことを強制するだけです.

これも時間の無駄であり、外部キー制約を無効にするコードを含めるために junit 基本クラスが肥大化します。おそらく、データベースの種類 (hsqldb など) をテストし、データベース固有の方法で無効にする必要があります。これはかなり悪いです。

dbunit がフレームワークの一部として自動的に外部キー制約を無効にするのに役立つ場合は、より良いかもしれませんが、これは行いません。彼らは方言を追跡しています...だから、これに使わないのはなぜですか? 最終的には、これらすべてがプログラマーに時間を浪費させ、すぐに立ち上がってテストすることを余儀なくさせるだけです。

3) XML を書くのは面倒です。これについてはこれ以上言う必要はありません。彼らはまた、それを行うための非常に多くの方法を提供しているため、問題が複雑になっていると思います. 本当に堅実な方法を1つ提供するだけで、それで完了です。

4) データが大きくなると、ID とそれらの一貫した正しい関係を追跡することは非常に困難です。

また、1 か月間プロジェクトに取り組んでいない場合、user_id 1 が管理者、user_id 2 がビジネス ユーザー、user_id 3 がエンジニア、user_id 4 が別のユーザーであることをどのように覚えていますか? これを確認するために戻ってくるのは、より多くの時間を無駄にします。任意の数値以外に意味のある取得方法があるはずです。

5) 遅いです。hsqldb を使用しないと、非常に遅いことがわかりました。そうである必要はありません。「箱から出して」行うのは簡単ではないため、構成を台無しにする方法も多数あります。それを正しく機能させるには、通過しなければならないこぶがあります。これはすべて、人々にそれを使用しないように促したり、使用し始めたときに腹を立てたりすることを奨励するだけです.

6) 一部の値は、日付のように何度も繰り返される傾向があります。デフォルトを指定するか、デフォルトをそこに入れるように指示しなくても、フレームワークに自動的にデフォルトを入れるとよいでしょう。そうすれば、必要な値だけでオブジェクトを作成し、残りをオフのままにすることができます。これは、必要がない場合、列の隅々まで指定するよりも優れています。

7) おそらく最も面倒なことは、最初のエントリにすべての値 (プレースホルダーが null であっても) を含める必要があることです。そうしないと、実際に指定した列が将来の行で選択されません。

DBunit には、[NULL] を実際の null 値に変換するための賢明なデフォルトもありません。手動で追加する必要があります。教えてください、dbunit でこれを行ったことのない人はいますか? 誰もが持っています。こんなはずじゃない！

これが意味することは、ポリモーフィック オブジェクトがある場合、最初の行で各サブクラスの結合テーブルへのすべての外部キーを、それらが null であっても宣言する必要があるということです。すべてのサブクラス パターンのテーブルを実行する場合でも、最初の行ですべてのフィールドを指定する必要があります。これはただひどいです。

私を満足させるものは何かありますか?それとも、より優れたデータベース テスト フレームワークの次のフレームワーク開発者になる必要がありますか?

ScalaDBTest と呼ばれる scala の dbunit を置き換える実用的な文法を作成しました。プログラム全体が動作します - 書くのに 2 日しかかかりませんでした。やるべきことがたくさんあります。

とにかく、DSL がデータベースにデータを入力するために使用している文法は順応性があり、それについてのフィードバックが欲しいです。

基本的な構文は次のようになります。それはとても簡単です：

これは、XML や SQL の挿入ステートメントよりも確実に優れています。

「:」や「=」を使って議論しました。前者の方が見栄えが良いですが、後者は自動的に入力できるようです。

レコードに「ラベルを付ける」という概念もあります。ある意味で、上記の構文は匿名レコードでした。ラベルはさまざまな方法で使用できるため、興味深い機能になります。

私はこの構文が嫌いです。ちょっと二言です。「-」を使用するのは正しくないように見えますが、「record」のような実際のコマンド ワードを使用する場合は、「->」を使用してそれらを区切る必要があります。

$label は単にラベルを繰り返すだけなので、文字列を再利用する方法として最小限のラベルを使用できます。$label.uncamel は、キャメルケースのように見える場所にスペースを追加します。

ラベルの背後にある考え方は、API が ID を覚えなくてもレコードにアクセスできるようにすることです。取得したい国オブジェクトが「カナダ」であることがわかっている場合は、ラベル「カナダ」を渡すだけで、それが一意の ID に変換され、データベースから取り出されます。

デフォルトのパラメータを指定できる例を次に示します。

ここで、本当の力を見ました。これら 3 つの「都道府県」レコードはすべて、4 つの列を持ちます。2 つの州はカナダからのものであるため、デフォルト値から自動的に継承されます。3 番目のケースでは、New York の United States で上書きします。必要に応じて組み合わせることができます。

実際には、実際にはいくつかの値しか気にしないことが多いため、これにより入力と認知負荷が大幅に節約され、残りは、必要なフィールドの欠落などについてデータベースを黙らせるための単なるプレースホルダーになる可能性があります。これは、ポリモーフィック オブジェクトのテストにも非常に役立ちます。

ここに別のものがあります：

このスニペットは、dbUnit のようなトリックを行わずに実際に null 値を配置できることを示しています。DbUnit では、カスタム文字列 ("[NULL]" など) を実際の null 値に変換するトランスフォーマーを最初に作成する必要があります。

実際、私たちはより表現力に富み、さまざまな表現や関数を提供してデータの生成を支援することができます。たとえば、$now は、今日の日付/時刻の適切にフォーマットされた SQL 日付を返します。これらの種類の機能を拡張して、テスト データの作成を容易にします。

とにかく、構文を本当にきれいにするための助けを探しています。いくらでも変えられるし、これは新鮮なので、あとで変えるよりも、最初からカッコいいものにしたいと思っています。

ありがとう

DBUnit を使用して DAO レイヤー メソッドをテストしようとしています。メソッドごとに異なるシード データのセットが必要です。

例：

getEmployeeById(Long id) には Employee テーブルからのデータが必要です

updateOrder(CustomerId cId) には Orders テーブルからのデータが必要です

setUp メソッドで一度にすべてのデータをロードする代わりに、異なるメソッドを実行する前に異なるシード データをロードするエレガントな方法はありますか?

ありがとうございました。

ID列を持つテーブルをDBユニットでロードしようとしています。id値を自分で設定できるようにしたい（データベースで生成されたくない）。

これが私のテーブルの最小限の定義です

Xに行を挿入するには、次のSQLを実行します

問題ない。しかし、次のdbユニットXMLデータセット（RS_7_10_minimal_ini.xml）を使用してこのテーブルをロードしようとすると

次の最小限のJUnit（DBTestCase）テストケースを使用します。

次の例外で失敗します

ID列の値が指定されている行を挿入する前に、DBユニットがIDをオンにしないようです。

JdbcDataBaseTesterから取得した接続で自分自身を実行しようとしましたが、うまくいきませんでした。おそらく、新しい接続か、データをdeDBにプッシュするために使用されたのと同じ接続ではありません。

何か案が？

たくさんのご協力ありがとうございました！

オクターブ

DAO レイヤー (JPA 上に構築されている) を分離してテストしようとしています。単体テストでは、DbUnit を使用してデータベースにデータを入力し、Spring Test を使用して ApplicationContext のインスタンスを取得しています。

SpringJunit4ClassRuner を使用しようとすると、ApplicationContext が注入されましたが、DbUnit の getDataSet() メソッドが呼び出されませんでした。

次に、 @RunWith アノテーションを削除しようとしました。これにより、 getDataSet() メソッドの問題が解決されました。しかし、今では ApplicationContext インスタンスが注入されなくなりました。デフォルトで DependencyInjectionTestExecutionListener を構成することになっている @TestExecutionListeners アノテーションを使用しようとしましたが、AppContext はまだ注入されません。

誰にもアイデアはありますか？これら 2 つのフレームワークを組み合わせるのは一般的に悪い考えですか?

編集: テスト クラスの残りのソースは次のとおりです。