プロジェクトのライフサイクルにおける非常に一般的なニーズは、統合テストの設定です。幸いなことに、Mavenはデフォルトのビルドライフサイクルの次の段階で、この正確なシナリオをサポートしています。 Lifecycle__Reference[ドキュメント]):



  • 統合前テスト


    :統合前に必要なアクションを実行する

テストが実行されます。これには、
必要な環境




integration-test ** :__必要に応じてパッケージを処理してデプロイする

統合テストを実行できる環境へ。




統合後テスト** :__統合後に必要なアクションを実行する

テストが実行されました。これには環境のクリーンアップも含まれます。

まず、http://maven.apache.org/plugins/maven-surefire-plugin/[maven-surefire-plugin]を設定して、

統合テストを標準ビルドライフサイクルから除外

します。

<plugin>
   <groupId>org.apache.maven.plugins</groupId>
   <artifactId>maven-surefire-plugin</artifactId>
   <version>2.17</version>
   <configuration>
      <excludes>
         <exclude>** ** /** IntegrationTest.java</exclude>
      </excludes>
   </configuration>
</plugin>


除外

はantスタイルのパス表現を介して行われるため、すべての統合テストはこのパターンに従い、

“で終了する必要があります。 IntegrationTest.java

“。

次に、https://codehaus-cargo.github.io/cargo/Maven2 plugin.html[

cargo-maven2-plugin

]が使用されます(https://codehaus-cargo.github.io[Cargo]はtop-が付属しています)。組み込みWebサーバーのためのすぐに使えるサポートのノッチ。もちろん、サーバー環境に特定の設定が必要な場合、cargoはアーカイブされたパッケージからサーバーを構築する方法と外部サーバーにデプロイする方法も知っています。

<plugin>
   <groupId>org.codehaus.cargo</groupId>
   <artifactId>cargo-maven2-plugin</artifactId>
   <version>1.4.8</version>
   <configuration>
      <container>
         <containerId>jetty8x</containerId>
         <type>embedded</type>
      </container>
      <configuration>
         <properties>
            <cargo.servlet.port>8080</cargo.servlet.port>
         </properties>
      </configuration>
   </configuration>
</plugin>

組み込みJetty 8 Webサーバーが定義されており、ポート8080でlistenしています。

新しいバージョンの貨物(1.1.0以降)では、

wait

フラグのデフォルト値は

falseに変更されました。この目標は統合テストの実行にのみ使用されるべきで、Mavenのライフサイクルに拘束されます。開発のためには、代わりに

cargo:run

目標を実行する必要があります – これは

wait = true__を持ちます。


package

mavenフェーズで

deployable

war


ファイルを生成するには、プロジェクトのパッケージ化が次のようになっている必要があります。


<packaging>戦争</packaging>

次に、新しい

integration


Mavenプロファイル

が作成され、このプロファイルがアクティブなときにのみ** 統合テストを実行できるようになります。標準ビルドライフサイクルの一部としては実行されません。

<profiles>
   <profile>
      <id>integration</id>
      <build>

         <plugins>
            ...
         </plugins>

      </build>
   </profile>
</profiles>

残りの設定をすべて含むのはこのプロファイルです。

これで、Jettyサーバーは

pre-integration-test

フェーズで

開始

し、

post-integration-test

フェーズで

停止

するように設定されました。

<plugin>
   <groupId>org.codehaus.cargo</groupId>
   <artifactId>cargo-maven2-plugin</artifactId>
   <configuration>
      <wait>false</wait>
   </configuration>
   <executions>
      <execution>
         <id>start-server</id>
         <phase>pre-integration-test</phase>
         <goals>
            <goal>start</goal>
         </goals>
      </execution>
      <execution>
         <id>stop-server</id>
         <phase>post-integration-test</phase>
         <goals>
            <goal>stop</goal>
         </goals>
      </execution>
   </executions>
</plugin>

これにより、

cargo:start

goalおよび

cargo:stop

goalsが、統合テストフェーズの前後に実行されます。 Mavenが設定を受け入れることができるように、2つの個別の

execution

定義があるので、


id


要素が両方に存在する(そして異なる)必要があります。

次に、

maven-surefire-plugin

設定を

integration

プロファイル内でオーバーライドする必要があるので、デフォルトのライフサイクルで除外された統合テストは

インクルード

されて実行されます。

<plugins>
   <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-surefire-plugin</artifactId>
      <executions>
         <execution>
            <phase>integration-test</phase>
            <goals>
               <goal>test</goal>
            </goals>
            <configuration>
               <excludes>
                  <exclude>none</exclude>
               </excludes>
               <includes>
                  <include>** ** /** IntegrationTest.java</include>
               </includes>
            </configuration>
         </execution>
      </executions>
   </plugin>
</plugins>

注目に値することがいくつかあります。

{空} 1

maven-surefire-plugin




test


目標は

integration-test

フェーズで実行されます。この時点で、Jettyはすでにプロジェクトをデプロイした状態で開始されているので、統合テストは問題なく実行されるはずです。

{空} 2。統合テストは実行に含まれるようになりました。これを達成するために、除外もオーバーライドされます – これはMavenがプロファイル内のオーバーライドプラグイン設定を処理する方法によるものです。基本設定は完全には上書きされませんが、プロファイル内の新しい設定要素で拡張されます。

このため、最初から統合テストを除外した元の

<excludes>

設定がまだプロファイルに存在しているため、オーバーライドする必要があります。そうしないと、

<includes>

設定と競合しますそれでもテストは実行されません。

{空} 3。ただし、

<execution>

要素は1つしかないため、

id

** を定義する必要はありません。

これで、プロセス全体を実行できます。


mvnクリーンインストール-Pintegration


結論

Mavenの段階的な構成では、プロジェクトライフサイクルの一部として統合プロセスを設定するプロセス全体をカバーします。

通常、これはContinuous Integration環境で、できれば各コミットの後に実行するように設定されています。 CIサーバーですでにサーバーが稼働していてポートを消費している場合は、貨物構成でそのシナリオに対処する必要があります。これについては、今後の記事で説明します。

このメカニズムの完全な設定については、https://github.com/eugenp/tutorials/tree/master/spring-rest-full[REST GitHub project]をチェックしてください。

プロジェクトを構築し、単体テストと統合テストをまとめるためのベストプラクティスについては、http://www.petrikainulainen.net/programming/maven/integration-testing-with-maven/[この記事をチェックアウト]をご覧ください。