Java / scalaに合わないdbunitのようなフレームワークはありますか？
私は、新しい軽量のデータベース作成フレームワークを作成することを考えていました。私は絶対にdbunitが嫌いです。私がやる前に、誰かがすでにやったかどうか知りたい。
Dbunitで嫌いなこと：
1）最も簡単な記述形式および使用開始形式は非推奨です。彼らはあなたが肥大化したフォーマットを使用することを望んでいます。 xmlスキーマが必要なものもあります。ええ、何でも。
2）行はユーザーが記述した順序ではなく、xmlファイルで定義されている順序でテーブルに挿入されます。外部キー制約が問題を引き起こさないような方法でデータを順序付けることができないため、これは本当に悪いです。これにより、それらを完全にオフにするという面倒な作業が必要になります。
また、これは時間を浪費し、外部キー制約を無効にするコードを含めるためにjunit基本クラスを肥大化します。おそらくデータベースタイプ（hsqldbなど）をテストし、データベース固有の方法で無効にする必要があります。これはかなり悪いです。
Dbunitがフレームワークの一部として外部キー制約を自動的に無効にするのを助けた方が良いかもしれませんが、彼らはそうしません。彼らは方言を追跡しています...だから、なぜこれを使ってみませんか？最終的に、これはすべてプログラマーに時間を浪費させ、すぐに立ち上がってテストを行わないことです。
3）XMLは書くのが面倒です。これについて詳しく言う必要はありません。彼らはそれを行うための非常に多くの方法も提供しているので、問題を複雑にしているだけだと思います。本当に堅実な方法を提供し、それを実行するだけです。
4）データが大きくなると、IDとそれらの一貫性のある/正しい関係を追跡することは非常に困難です。
また、1か月間プロジェクトに取り組んでいない場合、user_id 1が管理者、user_id 2がビジネスユーザー、user_id 3がエンジニア、user_id 4が別のものであったことをどのように覚えていますか？これを確認するために戻ると、さらに時間が無駄になります。任意の番号以外に、それを取得する意味のある方法があるはずです。
5）遅いです。 hsqldbを使用しない限り、非常に遅いことがわかりました。そうである必要はありません。 「そのまま」行うのは簡単ではないため、構成を台無しにする方法も数多くあります。正常に機能させるために通過する必要があるこぶがあります。これが行うすべては、人々がそれを使用しないことを奨励するか、彼らがそれを使用し始めたときに怒っていることです。
6）いくつかの値は、日付が好きで、多く繰り返す傾向があります。デフォルトを指定するか、フレームワークにデフォルトを自動的に入力させることは、あなたがそこにデフォルトを設定するように指示しなくてもいいことです。そのようにして、必要な値だけでオブジェクトを作成し、残りはそのままにしておくことができます。これは、列の隅や隅を指定する必要がない場合は確実に勝ります。
7）おそらく最も厄介なのは、最初のエントリにすべての値（ヌルプレースホルダーも含む）を含める必要があることです。そうしないと、将来の行で実際に指定した列が選択されません。
DBunitには、[NULL]を実際のNULL値に変換するための賢明なデフォルトもありません。手動で追加する必要があります。誰がこれをdbunitでやったことがないのですか？誰もが持っています。こんなふうになってはいけません！
これが意味することは、ポリモーフィックオブジェクトがある場合、nullであっても、最初の行の各サブクラスの結合テーブルにすべての外部キーを宣言する必要があるということです。すべてのサブクラスパターンのテーブルを作成する場合、最初の行のすべてのフィールドを指定する必要があります。これはひどいです。
私を満足させるものはありますか、それとも、より優れたデータベーステストフレームワークの次のフレームワーク開発者になるべきですか
私はDbUnitの本当の代替手段を知りませんし、 @ Joe で言及されているツールはどれも私の目にはありません：
- Incanto ：DBに依存しない
- SQLUnit ：データベースストアドプロシージャをテストするための回帰および単体テストハーネス（DbUnitの目的ではありません）
- Cactus ：コンテナ内テスト用のツール（データベースに役立つ場所がわかりません）
- Liquibase ：データベース移行ツール（データをロード/検証しません）
- ORMUnit ：データベースを初期化できますが、それだけです
- JMock ：DbUnitとまったく競合しません
そうは言っても、私は個人的にDbUnitを小規模および大規模なプロジェクトで何度か正常に使用しており、特に nitils とそのDbUnitモジュールを使用している場合は非常に便利です。これは、完璧で改善できないという意味ではありませんが、適切なツール（カスタムメイドまたはユニティルのようなもの）を使用すると、それを使用することはまともな経験になります。
だからあなたのポイントのいくつかに答えさせてください：
1）最も簡単な記述形式および使用開始形式は非推奨です。彼らはあなたが肥大化したフォーマットを使用することを望んでいます。 xmlスキーマが必要なものもあります。ええ、何でも。
DbUnitは、フラットまたは構造化されたXML、XLS、CSVをサポートします。どの革命的なフォーマットを使用しますか？ところで、XMLを使用する場合、DTDまたはスキーマは必須ではありません。しかし、検証やオートコンプリートなどの便利な機能がありますが、それはどうですか？また、Unitilsはそれを簡単に生成できます。 データベース構造のXSDまたはDTDの生成 を参照してください。
Dbunitがフレームワークの一部として外部キー制約を自動的に無効にするのを助けた方が良いかもしれませんが、彼らはそうしません。彼らは方言を追跡しています...だから、なぜこれを使ってみませんか？最終的に、これはすべてプログラマーに時間を浪費させ、すぐに立ち上がってテストを行わないことです。
彼らはあなたのパッチを待っています。
一方、Unitilsは、制約を透過的に処理するサポートを提供します。 制約の無効化とシーケンスの更新 を参照してください。
3）XMLは書くのが面倒です。これについて詳しく言う必要はありません。彼らはそれを行うための非常に多くの方法も提供しているので、問題を複雑にしているだけだと思います。本当に堅実な方法を提供し、それを実行するだけです。
痛みは主観的だと思いますが、特にスキーマとオートコンプリートを使用する場合、痛みは感じません。あなたが提案している特効薬は何ですか？
4）データが大きくなると、IDとそれらの一貫性のある/正しい関係を追跡することは非常に困難です。
それらを小さく保つ、それは知っている ベストプラクティス 。既知のベストプラクティスに反して文句を言う...
また、1か月間プロジェクトに取り組んでいない場合、user_id 1が管理者、user_id 2がビジネスユーザー、user_id 3がエンジニア、user_id 4が別のものであったことをどのように覚えていますか？これを確認するために戻ると、さらに時間が無駄になります。任意の番号以外に、それを取得する意味のある方法があるはずです。
はい、タスクの切り替えは逆効果です。ただし、低レベルのデータで作業しているため、それらがどのように表現されるかを知る必要があります。もちろん、より高レベルのAPIを使用しない限り、魔法の解決策はありません（ただし、DbUnitの目的ではありません）。
5）遅いです。 hsqldbを使用しない限り、非常に遅いことがわかりました。そうである必要はありません。 「そのまま」行うのは簡単ではないため、構成を台無しにする方法も数多くあります。正常に機能させるために通過する必要があるこぶがあります。これが行うすべては、人々がそれを使用しないことを奨励するか、彼らがそれを使用し始めたときに怒っていることです。
これは、DbUnitではなく、データベースとJDBCに固有のものです。可能な限り高速に処理したい場合は、H2のような高速データベースを使用します（より良い不可知論的な方法がある場合は、それについて学んでうれしいです）。
6）おそらく最も厄介なことは、最初のエントリにすべての値（ヌルプレースホルダーも含む）を含める必要があることです。そうしないと、将来の行で実際に指定した列が選択されません。
nitils-Home-JavaPolis 2008 や nit Testing：unitils＆dbmaintain のようなプレゼンテーションで言及されているUnitilsを使用する場合は該当しません。
私を満足させるものはありますか、それとも、より優れたデータベーステストフレームワークの次のフレームワーク開発者になるべきですか
物事を改善できると思うなら、おそらく既存のソリューションに貢献してください。それが不可能で、キラーデータベーステストフレームワークを作成できると思われる場合は、それを実行してください。しかし、忘れないでください、暴言は簡単で、独自のソリューションを使用してソリューションを思い付くのはそれほど簡単ではありません。
DbUnit開発者として、私は批判に感謝し、あなたに部分的に同意しなければなりません。現在、次のDbUnitメジャーリリースの設計を開始しています。ディスカッションと開発の両方に参加することをお勧めします。
あなたの質問は実際にはDbUnitに関連しているのではなく、DbUnitの代替に関連しているので、私はあなたのポイントに答えるつもりはありません。とにかく、ポイント7が完全に偽であることを強調したいだけです。最初の行のすべての列を指定する必要はありません。この機能は列センシングと呼ばれます。あなたは自分でそれを理解するのに十分賢いので、なぜデフォルトで有効にされていないのかはお話ししません。
Scaladbtestの詳細な検討を行い、彼らのアイデアを統合できることを期待します。
DBUnitを使用して同様の懸念に直面したとき、私はこれを見つけました： http://dbsetup.ninja-squad.com/index.html テストデータを個別のファイルで表す代わりに、すべてのDBコンテンツがJavaクラス自体に含まれています。
Spring Frameworkを使用する場合（または、少なくともテストに使用することを気にしない場合）、 Spring DBUnit は現在私が知っていて使用している単純なDBUnitに代わる最良の（維持された）代替物。彼らのウェブサイトを引用：
Spring DBUnitは、Springテストフレームワークと一般的なDBUnitプロジェクトとの統合を提供します。テストが完了したら、単純な注釈を使用して、予想されるテーブルの内容をチェックするだけでなく、データベーステーブルをセットアップおよび分解できます。
Spring DBUnitは、DBユニットテスト（DBUnitを使用）の「やや公式な」Springソリューションのようです。少なくとも図書館の著者/維持者であるPhil Webbは、SpringSource/Pivotalで働いています。
DBUnitを使用し、いくつかのラッパーを使用して、粗いエッジを滑らかにします。機能を補完またはオーバーラップできる素敵なツールは Jailer です。参照データベースからデータのサブセットを抽出し、これをDBUnit互換のXMLファイル、または外部キー制約を尊重する「トポロジカルにソートされたDMLファイル」として保存できます。
あなたは素晴らしい点を挙げています。
私はここ数年、多くのWebポータルで働いてきました。そのほとんどはPHPでしたが、一部のJava.
そして、あなたと同じように、ここ数年、フレームワークと単体テストの開発者は、過去10年間でストレージの処理がどれほど変わったかを認識していないようです。 create/insert/truncateステートメントをデータベースに送信するだけでは不十分です！大規模に運用している場合は、あらゆる種類のストレージバックエンドを採用することになり、ホットコンテンツを高速にプッシュするためにレイヤーで整理されます。さらに、データベースの面では、データのパーティション分割の問題があります。適切な外部キーの抽象化がない場合、ストレージの設定が変更されたときに確実に気が狂います。また、外部キーの優先順位によるフィクスチャの順序付けには多くの落とし穴がありますが、DBUnitを使用した実際の解決策はまだわかりません。
とにかく、ポイントはユニットテストのための基本的なデータベースストレージだけで、複雑なストレージセットアップには十分ではありません。ライブ環境で問題を再現できず、維持するのが苦手だからです。
おたくのように聞こえたくない場合：大丈夫な場所の1つはRuby on Rails。それは、人々が実際にいくつかの考えを入れたように見える永続的なモデルの概念を持っています。 PHPを扱っている場合は、Symfonyが最適です。 Doctrineをデフォルトで含めることで制限され、DB中心でもありますが、きれいなインターフェイスと優れた拡張性を備え、Railsフィクスチャシステムを完全にコピーしました。今のところ自作のソリューションに固執する必要がありますが、それらは大丈夫です。
ソフトウェアテストでデータベースのセットアップと検証に使用できるJDBDT（Java Database Delta Testing）というライブラリをリリースしました。
http://jdbdt.org をご覧ください
ベスト、エドゥアルド
実際、DBUnitの状況はいらいらすることがあります。一部の問題は Marc Philippdbunit-datasetbuilder で解決されます。特に validator と組み合わせた場合は非常に早いですステージ。 [〜＃〜] sze [〜＃〜] で動作を確認できます。
免責事項：参照されているすべてのgithub-resourcesは私によって管理されています。
上記の懸念事項のいくつかに対処するため、DbUnitのラッパーとして Daleq を作成しています。 XMLファイルの編集に依存するのではなく、ユニットテスト内でDBを作成できます。
私もDBUnitで同様の問題を抱えていました。特に、ローカルの開発データを作成し、実際のデータベースからデータをエクスポートするために使用します。インポートできないデータセットをエクスポートするいくつかのケースに遭遇しました。
これにより、新しいライブラリを作成することになりました： https://github.com/jeffskj/phonydata
これはデータの非常にコンパクトな表現を可能にするデータセットを定義するためにgroovy DSLを使用し、単なるgroovyコードなのでランダムデータを生成するようなクールなことを可能にします。
github で利用可能なペダルローダーと呼ばれるグルーヴィーなDSLベースのフレームワークをリリースしました。ドキュメント ここ 。
JPAエンティティレベルの抽象化を直接操作できます。 groovyスクリプトであるため、すべてのgroovyコンストラクトを使用できます。
Studentと呼ばれるJPAエンティティを基に、id、name、gradeというフィールド（データベース列ではなく、マップされたフィールド）を含むテーブルに行を挿入するには、次のようにします。
allStudents = table(Student, ['id', 'name', 'grade']) {
row 1, 'Joe', Grade.A
rowOfInterest = row 2, 'John', Grade.B
}
Gradeは、データベース列にマップされるStudentクラスの列挙です（おそらく、JPA 2.1 @Convertアノテーションを使用します）。 allStudentsは行を保持するリストであり、rowOfInterestは特定の行への参照です。これらのプロパティ（allStudentsおよびrowOfInterest）は、ユニットテストで使用可能になります。
Spring構成とSpecs2テストを使用する代替案が見つかります ここ