68

Hibernate（およびSpring）を使用してデータベースなどからデータを取得するMavenで構築しているプロジェクトがあります.

私のプロジェクトのDAOの「テスト」はSpringのAbstractTransactionalDataSourceSpringContextTestsものを拡張して、テスト中のクラスにDataSourceを接続して、クエリ/ Hibernateロジックを実際に実行したり、データをフェッチしたりできるようにします。

他のいくつかのプロジェクトでは、これらのタイプのテストを HSQL データベース (メモリ内またはファイルを指す) と組み合わせて使用​​し、外部データベースに依存することなく実際のデータベース クエリ ロジックを効率的にテストできるようにしました。これは、外部の依存関係を回避し、テストを実行する前のデータベースの「状態」（それぞれがロールバックされるトランザクションにラップされている）が明確に定義されているため、うまく機能します。

私はこれらのテスト (統合テストのルーズなフレーバー) を Maven で編成する最良の方法について興味があります。これらのテストを に保持するのは少し汚い気がしますsrc/test/javaが、私が読んだ限りでは、Maven との統合テストを編成するための一貫した戦略や実践はないようです。

私がこれまでに読んだことから、Failsafe プラグイン(または Surefire の 2 番目のインスタンス) を使用してそれをintegration-testフェーズにバインドし、カスタムの起動またはシャットダウン ロジック (起動など) をバインドすることもできるようです。 /HSQL インスタンスの停止)pre-integration-testまたはに移動しpost-integration-testます。しかし、これは本当に最善の方法でしょうか？

だから私の質問は基本的に - これを Maven で整理する上で一般的に受け入れられているベストプラクティスは何ですか? ドキュメントで一貫した答えを見つけるのに苦労しています。

私がしたいのは：

  • 単体テストを統合テストから分離して、testフェーズ中に単体テストのみが実行されるようにする
  • pre-integration-testカスタムの起動/シャットダウン ロジックをおよびにバインドする機能post-integration-test
  • 統合テストからのレポートを単体テストの Surefire レポートとマージ/提示する
4

4 に答える 4

26

これを行う非常に簡単な方法は、JUnitカテゴリを使用することです。

その後、テストフェーズ中にいくつかのテストを簡単に実行し、統合テストフェーズ中に別のテストを実行できます。

所要時間は数分で、必要な手順は3つだけです。

  1. マーカーインターフェイスを定義する
  2. 分割するクラスに注釈を付ける
  3. Mavenプラグインを構成します。

完全な例をここに示します。 https://stackoverflow.com/a/10381662/1365383

于 2011-07-04T14:42:23.003 に答える
21

いくつかのガイドラインが記載されたこのコードハウスページがあります。フェイルセーフプラグインはちょっとしたハックで、Eclipseでの単体テストの実行は非常に複雑になります。私はあなたが説明していることを大まかに行います。

src / itest / javaで統合テストを定義します。統合テスト前のフェーズでは、次のようにします。

  • ターゲット/テストクラスをクリアする
  • build-helper-maven-pluginのadd-test-sourceゴールを使用して、itestソースの場所を追加します
  • カスタムMojoを使用して、構成からsrc / test / javaを削除し、単体テストが再度コンパイルされないようにします（これはあまり好きではありませんが、単体テストと統合テストの分離を維持する必要があります）。
  • コンパイラプラグインを使用して統合テストをコンパイルします

次に、統合テストフェーズで、surefire-pluginを使用してテストを実行します。

最後に、整理された目標を統合テスト後のフェーズにバインドします（ただし、テストのteardown（）を使用して整理することができるため、通常は必要ありません）。

レポートフェーズが経過したため、テスト結果をマージする方法はまだ見つかりませんが、レポートに合格することがそれほど重要でない限り、統合テストを追加のボーナスと見なす傾向があります。

更新：Jettyの目標を使用するのではなく、統合テスト内からJettyを実行できることを指摘する価値があると思います。これにより、テストをより細かく制御できます。この回答と参照されているブログから詳細を入手できます。

于 2009-08-04T18:44:06.303 に答える
7

この優れたブログ投稿では、3 つのオプションが提案されています。

1) 統​​合テスト用の個別のモジュール

2) 異なるソース ディレクトリ

3) ファイル名のパターンの違い

私はまだ3つすべてを試していないので、私が好む意見を提供することはできません.

于 2010-07-19T10:12:11.937 に答える
1

私は2番目のオプションである別のソースディレクトリを好みますが、統合テストまたはパッケージの除外をITで終わらせなければならないのは非常に面倒です。

これを避けるために、私はこの設定で終わった：

<properties>
    <testSource>src/test/java</testSource>
    <testSourceResource>src/test/resources</testSourceResource>
</properties>
<build>
    <testSourceDirectory>${testSource}</testSourceDirectory>
    <testResources>
            <testResource>
            <directory>${testSourceResource}</directory>
            </testResource>
        </testResources>
.....
.....

次に、統合と受け入れテストのために、異なるプロファイルで両方の変数をオーバーライドします。

<profiles>
  <profile>
   <id>acceptance-tests</id>
   <properties>
    <testSource>src/acceptance-test/java</testSource>
    <testSourceResource>src/acceptance-test/resources</testSourceResource>
   </properties>
  </profile>
 <profile>
   <id>integration-tests</id>
    <properties>
    <testSource>src/integration-test/java</testSource>
    <testSourceResource>src/integration-test/resources</testSourceResource>
    </properties>
  </profile>
.....
.....
.....
于 2013-09-06T10:15:35.523 に答える