我々は、生産とテストランタイムのための二重のpersistence.xmlファイルを使用しますが、それが唯一のクラスパスに関連する問題です(私たちはEclipseを使用しますが、WTPプラグインに大きく依存しません)。この2つの唯一の違いは、実動バージョンにエンティティ定義が含まれていないことです。
私たちはJPAをテストするために模擬フレームワークを使用しません。これは、テストに何の価値も追加しないためです。このテストでは、PostgreSQLデータベースと通信するJPAを使用した実際のデータアクセスが実行されます。
私たちのテスト手法は、永続化層のSpringテストフレームワーク:トランザクション内テストに基づいています。私たちのアプリケーションはSpringをベースにしていますが、Springのテストクラスを利用したい任意のアプリケーションでも同様にこの方法を使用できます。本質は、各テストがコミットしない単一のトランザクション内で実行され、最後に(tearDownで)自動的にロールバックされることです。これは、データの汚染とテストの依存関係の問題を、非常に見苦しい、邪魔にならない透明な方法で解決します。
Springテストフレームワークは、マルチトランザクションテストを可能にするために柔軟性がありますが、テストの10%を超えない特殊なケースです。
まだlegacy support for JUnit 3.8を使用していますが、新しいSpring TestContext FrameworkはJUnit 4に非常に魅力的です。
トランザクション内のテストデータを設定するために、私たちはビジネスエンティティを構築する社内ユーティリティクラスを使用します。すべてのテスト間で共有されるため、維持してサポートするオーバーヘッドは、テストデータを設定するための標準的で信頼性の高い方法のメリットがあるため、非常に軽量です。
スプリングDIはテストを簡潔かつ自己記述的にするのに役立ちますが、重要な機能ではありません。
このタイプのテストは単体テストではありません。私はタイプの統合テストだと思う。単体テストを書くときには、すべての依存関係がモックされたクラスをテストします。したがって、ユニットテストでは実際のデータベース(インメモリデータベースでさえ)を使用することは有効ではありません。 –
これは完全な統合テストではありません。それは有効です!単なる単体テストではありません。 – Gilberto