35

これは単純な質問かもしれませんが、私はjunitフレームワークとhibernateフレームワークの両方に不慣れであり、主にhibernateを呼び出すアプリケーションの単体テストを行うための最良の方法は何か、またはそうする必要があるかどうか疑問に思っていました。

ここでのベストプラクティスは何ですか？

編集：
ここでは春が大きな提案のようです。残念ながら、これは1つのプロジェクトを食い止めるには少し多すぎるかもしれません。Junit、Hibernate、Springはすべて私にとって新しいものであり、これらはすべて私が身に付けたいテクノロジーですが、それらすべてを1つのプロジェクトに組み込むことは私には圧倒されるかもしれません。

チュートリアルや本の提案へのリンクは大歓迎です。

4

10 に答える 10

19

単体テストと統合テストの違いに注意してください。

単体テストは、外部に依存することなくコードをテストする必要があります。これらの依存関係は、JMock などのフレームワークを使用してモック化されます。

統合テストも重要ですが、実行に時間がかかるという大きな欠点があります。数秒で何千もの真の単体テストを実行できますが、統合テストとは異なります。

プロジェクト/開発チームの規模によっては、統合テストよりも真の単体テストを優先したい場合があります。どちらのスタイルのテストも重要ですが、リソースが不足している場合は、単体テストを使用することをお勧めします。

私は自分でアプリケーションを作成し、Web (Spring MVC を使用すると簡単です) とサービス層、およびドメイン オブジェクトを単体テストしました。しかし、遅い統合テストをたくさん書きたくなかったので、DAO はそのままにしておきました。スタッフがもっと多かったら、統合テストも行ったでしょうが、この場合、費やした時間に見合う価値があるとは感じませんでした.

于 2008-12-30T15:43:33.887 に答える
5

ベストプラクティスについて：

可能であれば、組み込みデータベースを使用してテストを実行します。これにより、テストを実行するためだけに完全にデプロイされたリレーショナルデータベースが不要になります（ローカル、または継続的ビルドサーバーがある場合）。そうすれば、（必然的に）ロールバックなどについて心配する必要もありません。必要なときにデータベースを再作成するだけです。組み込みデータベースを使用したテストでは、特定の本番データベースを使用するときに発生する可能性のある特性はテストされませんが、コードはテストされます。これで十分です。

JUnitの拡張機能であるDbUnitを使用して、Hibernateテストを実行する前に、データベースを予想される行で簡単に埋めて、既知の状態にすることもできます。

于 2008-12-30T14:38:12.773 に答える
3

ベストプラクティス？私は Spring を使用し、すべてのテストをトランザクション対応にしています。データベースの状態を変更しないように、テストを実行してすべての変更をロールバックします。

于 2008-12-30T14:22:33.910 に答える
2

テストにはメモリ内のhsqldbを使用するのが好きです。各休止状態のPOJOのプロセスは次のとおりです。

  1. オブジェクトを作成します
  2. それをDBに永続化する
  3. セッションをクリアする
  4. DBから入手
  5. オブジェクトが等しいことを表明します。

DAOの場合、メソッドを正確にテストするのに十分なオブジェクトを作成して永続化し、テストを実行して、他のテストと干渉しないように必要に応じてオブジェクトを削除します。

于 2008-12-30T15:07:52.807 に答える
2

Hibernate のソースには多くの単体テストが含まれています。それらを調べて、同様のアプローチを採用することをお勧めします。

書籍「Java Persistence with Hibernate」用にサンプル アプリケーションが開発したCaveatEmptorも参照できます。

于 2008-12-30T16:58:29.260 に答える
1

ドメイン リッチ モデルに Hibernate を使用している場合、ユニット テスト ドメイン ロジックは POJO をテストするのと同じくらい簡単で、Hibernate は邪魔になりません。ここでの唯一の注意点は、双方向マッピングの場合、単体テストのために両側でオブジェクトを設定する必要がある場合があることです。

データベースとの統合テストは、通常、単純なマッピングでは行われません。ただし、単一テーブルの継承などの精巧なマッピングの場合に推奨されます。ここで覚えておくべき唯一のことは、明示的にデータベースにフラッシュする必要がある場合があることです。

于 2011-05-25T09:42:20.980 に答える
0

ここでSpringを使用できます。

優れた単体テストフレームワークがあり、CRUD opsをテストしてから、変更をロールバックするために使用できます。データベースを毎回リロードする機能がない場合に最適です。

于 2008-12-30T14:23:46.093 に答える
0

リクエストを Hibernate に渡す単純なレイヤーを作成します。次に、 EasyMockやJMockなどのモッキング ライブラリを使用して、Hibernate ベニア レイヤーがアプリケーション クラスによって正しく呼び出されていることを確認します。これは、部分的に完成したJMock の本にうまく説明されています (「すべてが嘲笑されている」というテストの匂いまでスクロールします)。

于 2009-01-11T09:49:24.077 に答える
0

確かに、Hibernate で記述されていない場合は、永続層を単体テストしますよね?

Hibernate を使用して実装された特定の永続化インターフェイスを作成し、いくつかのサンプル オブジェクトをインスタンス化し、CRUD 操作を実行し、JUnit に操作が成功したことをアサートするように依頼します。他のクラスと同じです。

于 2008-12-30T14:21:40.527 に答える