Integration Testing with the Maven Cargo plugin

A very common need in the lifecycle of a project is setting up integration testing. Luckily, Maven has built-in support for this exact scenario, with the following phases of the default build lifecycle (from the Maven documentation):

  • pre-integration-test: Perform actions required before integration tests are executed. This may involve things such as setting up the required environment.
  • integration-test: Process and deploy the package if necessary into an environment where integration tests can be run.
  • post-integration-test: Perform actions required after integration tests have been executed. This may including cleaning up the environment.

First, the maven-surefire-plugin is configured so that integration tests are excluded from the standard build lifecycle:

<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>

Exclusions are done via ant-style path expressions, so all integration tests must follow this pattern and end with “IntegrationTest.java“.

Next, the cargo-maven2-plugin is used, as Cargo comes with top-notch out of the box support for embedded web servers. Of course if the server environment requires specific configuration, cargo also knows how to construct the server out of an archived package as well as deploy to an external server.

<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>

An embedded Jetty 8 web server is defined, listening on port 8080.

In newer version of cargo (1.1.0 upwards), the default value of the wait flag has been changed to false, due to this bug, for cargo:start. This goal should only be used for running integration tests and is bound to the Maven lifecycle; for development, the cargo:run goal should be executed instead – which has wait=true.

In order for the package maven phase to generate a deployable war file, the packaging of the project must be: <packaging>war</packaging>.

Next, a new integration Maven profile is created to enable running the integration tests only when this profile is active, and not as part as the standard build lifecycle.

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

         <plugins>
            ...
         </plugins>

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

It is this profile that will contain all the remaining configuration.

Now, the Jetty server is configured to start in the pre-integration-test phase and stop in the post-integration-test phase.

<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>

This ensures the cargo:start goal and cargo:stop goals will execute before and after the integration-test phase. Note that because there are two individual execution definitions, the id element must be present (and different) in both, so that Maven can accepts the configuration.

Next, maven-surefire-plugin configuration needs to be overridden inside the integration profile, so that the integration tests which were excluded in the default lifecycle are will now included and run:

<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>

There are a few things worth noting:

1. The test goal of the maven-surefire-plugin is executed in integration-test phase; at this point, Jetty is already started with the project deployed, so the integration tests should run with no problems.

2. The integration tests are now included in the execution. In order to achieve this, the exclusions are also overridden – this is because the way Maven handles overriding plugin configurations inside profiles. The base configuration is not completely overridden, but rather augmented with new configuration elements inside the profile. Because of this, the original <excludes> configuration, which excluded the integration tests in the first place, is still present in the profile, and needs to be overridden, or it would conflict with the <includes> configuration and the tests would still not run.

3. Note that, since there is only a single <execution> element, there is no need for an id to be defined.

Now, the entire process can run:

mvn clean install -Pintegration

Conclusion

The step by step configuration of Maven covers the entire process of setting up integration process as part of the project lifecycle.

Usually this is set up to run in a Continuous Integration environment, preferably after each commit. If the CI server already has a server running and consuming ports, then the cargo configuration will have to deal with that scenario, which I will cover in a future post.

For a fully running configuration of this mechanism, checkout out the REST github project.

Also check out this article for best practices of structuring a project and organizing the unit and integration tests.

I usually post about Dev stuff on Google+ - you can follow me there:

Get My 3 Spring eBooks
Learn how to properly build Web App with Spring (and how to prototype 90% of it very quickly)
×
Build Web App with Spring (and prototype it to 90% very quickly)

, , ,

  • http://ali.tokmen.com/ S. Ali Tokmen

    Hi Eugene

    Great article! I have a small comment, thought:

    “Notice the wait flag being set to true – this is because for the newer versions of cargo (1.1.0 upwards), the default value of the of the flag has changed from true to false, due to this bug. We want to be able to start the project by simply running mvn cargo:start, especially during the development phase, so the flag should be active. However, when running the integration tests we want the server to start, allow the tests to run and then stop, which is why the flag will be overridden later on.”

    CARGO 1.1.1 and onwards actually simplifies this a lot:

    * The default value for wait is indeed false. That’s because cargo:start is supposed to be used for integration testing only.
    * If you want to run the container (for manual testing), you should use the cargo:run goal -so no more trying to set the wait parameter correctly.

    Cheers

    S. Ali Tokmen
    http://ali.tokmen.com/

    • baeldung

      Thanks for the info – integrated into the article.

  • Pingback: JS Unit Testing | i-proving.com

  • adrianmoya

    Great article, I’m still learning maven and you have help me a lot with my intended setup.