2016-06-23 15 views
5

src/testのユニットテストを他のユニットテストと置き換えて、*Integr*Test,*ITTestなどのパターンで区別するか、src/itにする必要がありますか(Mavenプラグインを開発し、 maven-invoker-plugin)?maven-failsafe-pluginを使用しているときに統合テストをどこに保存すべきですか?

ユニットテストと統合テストの両方が同じ場所にある場合(たとえMavenプロファイルで制御されていたとしても)、私には十分にクリーンではないように見えるからです。

+1

あなたが言ったことはそれがきれいではないということは、あなたが好きではないかもしれないあなたの単体テストとしてそれらがクラスパスを得る正しい原因です。したがって、ITを含むモジュールを完全に分離することが最善です。すでに述べたように 'src/test/java'を使ってそれらを探し、ITの命名規則に従います。 – khmarbaise

+0

@khmarbaise:説明のおかげで、Apache Mavenプロジェクトのコミッタの一人からまっすぐに来てくれてありがとう!私はあなたが言っていることを理解していますが、別のディレクトリにあれば、あなたの ' test'の依存関係は異なるでしょう。彼らはそうではありません。私も理解していないことは、(この件でかなり読んでいるにもかかわらず)、なぜこの場合に別のプラグインが必要なのかです。統合テスト段階で呼び出される 'maven-surefire-plugin'のもう一つの目標は、単純にあったでしょうか? – carlspring

答えて

5

maven-surefire-plugin(test)のように、最初のmaven-fails-pluginはデフォルトで別のライフサイクルフェーズ(統合テスト)で実行されます。さらに、統合テストが失敗したかどうか確認する場合は、post-integration-testテストフェーズでverifyゴールを実行するようにmaven-failsafe-pluginを設定することができます。これは自由に設定することができます。

私の心には1つの質問があります。 10個のモジュールがあり、今では統合テストをしたいと思っていますか?彼らはどのモジュールに属していますか?だから、彼らが10個のモジュールのどれにも属していないので、別のモジュールを持つのが最善です。

maven-surefire-pluginとは別に、既定のライフサイクルで既に設定されています。はい、補足的な目標が考えられますが、異なるプラグインを使用するのは混乱します。ここでは懸念の分離が重要です。別に全体のデフォルト設定から...これらのプラグインは、より大きなコードベースを共有するが、違いがある...

も何すでにTunakiで述べてきたことは、サーバなどintegration-testやシャットダウンのようなもののようなセットアップもののために、pre-integration-testですダウンサービス/サーバーpost-integration-test段階です。これはユニットテストでは決して起こりません。

別のモジュールを使用すると、ユニットテストとは異なる依存関係(クラスパス)を持つことを意味するITをセットアップするのが簡単になります。たとえば、Arquillian.orgのような単体テストでは決して使用しないものがあります。これは単一のモジュールで処理することはできません...ここでも懸念の分離です。

さらに、統合テストはデフォルトでは並列化できませんでしたが、単体テストは定義によって定義することはできません。

フォルダのレイアウトはどうですか?統合テストモジュールでは、単純にsrc/test/javaフォルダを使用することができます。これは、補足的な設定(たとえば、build-helper-maven-pluginなど)を必要としないため、設定パラダイムよりも慣習に従いやすくなります。

そしてない方が良いビルド(CI)で実行されているものを制御することができます忘れて...

そして、もう一つの重要なヒント。通常、インテグレーションテストはインフラストラクチャに関連していることが多いので、そこでは失敗を無視することが有用な場合があります。checkのメイブフェイルセーフプラグインの目標を使用して処理できます。

ITモジュールの例はhereです。

8

src/itは、プラグインの統合テストに使用することを前提としています。これはStandard Directory Layoutに記載されています。

maven-failsafe-plugin

、デフォルトでは、ユニットテストのために、 ${project.build.testSourceDirectory}の内側にあなたの統合テストのために maven-surefire-pluginとして which is the sameを見ていきます。デフォルトでは、これは src/test/javaに対応します。ユニットテストのため naming conventionは異なる

<includes> 
    <include>**/IT*.java</include> 
    <include>**/*IT.java</include> 
    <include>**/*ITCase.java</include> 
</includes> 

:統合テストをnaming convention以下により明確作られ

<includes> 
    <include>**/Test*.java</include> 
    <include>**/*Test.java</include> 
    <include>**/*TestCase.java</include> 
</includes> 

をそれらが同じソースフォルダ(src/test/java)に存在するだろうが、名前の違いによって明確に区別されます。また、これはデフォルト設定であるため、余分な設定は必要ありません。

あなたは他のオプションを持つことができ、言った:

  • は、異なるソースフォルダ内の統合テストを置きますが。これにはいくつかの設定が必要です。build-helper-maven-plugin:add-test-sourceゴールを使用してカスタムフォルダをテストソースフォルダとして追加する必要があります。
  • 統合テストのみを含む異なるモジュール(マルチモジュールのMavenプロジェクトがある場合)を使用します。
+0

詳細な説明をありがとう!それは多くをクリアする!おそらく別の質問になるはずですが、@ khmarbaiseの上記のコメントで私の質問に返信することはできますか? – carlspring

+0

@carlspring私はITのための新しいプラグインを作成する正確な理由がわからないことは怖いです。 IT部門は単体テストとはまったく異なっているため、統合テストには前段階と後段階がありますが、単体テストではそうではありません。通常、IT部門は、それらを実行するためのカスタム環境をセットアップする必要があります(たとえば、サーバーの起動など)。私は個人的には別のディレクトリにITを持っていないでしょう:いくつかの設定が必要です。別のモジュールを持つIMOは、きれいなソリューションで、マルチモジュールプロジェクトを既に持っているときには完璧です(私は別の方法でモジュールを使うつもりはないと思います)。 – Tunaki

+0

ありがとう!これは説明として理にかなっていますが、私は 'maven-surefire-plugin'の余分な目標のほうがほぼ同じ効果を得ていると確信しています。しかし、おそらく、私がまだ気づいていないことが示唆されています。もう一度、お時間をありがとう! – carlspring

関連する問題