Integration and unit test strategies with maven2

Maven2 introduces a build lifecycle with different phases as follows (the list is not complete):

  • validate – validate the project is correct and all necessary information is available
  • compile – compile the source code of the project
  • test – test the compiled source code using a suitable unit testing framework. These tests should not require the code be packaged or deployed
  • package – take the compiled code and package it in its distributable format, such as a JAR.
  • integration-test – process and deploy the package if necessary into an environment where integration tests can be run
  • verify – run any checks to verify the package is valid and meets quality criteria
  • install – install the package into the local repository, for use as a dependency in other projects locally
  • deploy – done in an integration or release environment, copies the final package to the remote repository for sharing with other developers and projects.

As you see, there are two different test phases: test and integration-test. Unfortunately maven2 does not provide two different sources directory for the different test contexts, making it quite difficult to organize and setup the test environment.

Chatting with users and developers at the maven irc channel (irc:// and searching the net I found two different solutions to this particular problem.

The third solution presented in this article is a tricky usage of the surefire plugin configuration that is doing the best job for me (and other developers at Orientation in Objects).

Depending on your IDE, project layout and personal preferences you might prefer another solution than I have chosen for my projects.

ITests in a separate POM Project

One solution often found in the web is to outsource the integration tests to a external maven2 artifact, most of them create a separate pom project for that purpose.

This solution is interesting if you are not using a flat project structure. Multiprojects are natively support by maven2.

As the artifact where the sources are placed has the pom packaging, it leads to problems if you want the sources to be added to your eclipse project, specially if you are using the eclipse maven plugin.

Different source directories

This would be definitely the most elegant solution: place each set of test cases in a separate source folder:

The show stopper for me at the moment is that I cannot make the eclipse plugin add the itest source folder to build path as a source folder.

Using the maven-build-helper plugin does not solve the problem either, since it will add the test source output directory to the standard tests output directory, so your itests get fired in the normal unit-test test phase as well.
One test source folder, different packages

In order to get the eclipse plugin generating the correct project settings I have chosen to have all tests in one source folder and separete them through special package names. Depending on the package name I grouped them to sets and binded them to different build lifecycle phases. The package name is one way, another way would be to have them grouped by classname/ filename patterns.

At the moment my pom.xml hast the following configuration:

I group my different tests by special package names, in this case:

  • itest for integration test
  • utest for unit tests

This way I could create several sets of tests (funtional tests, performance tests, etc.), have them grouped by the package name and bound to different phases.

The main trick here is to have all tests compiled but not fired. This is archieved by adding the true setting to the main surefire configuration.

The next step is to bind different executions of the plugin to the respective phases. There are lots of articles out there on how to perform a deployment before integration-test phase (so far beeing out of scope for this article).

Here are some links to this topic:

Feel free add comments to this article!

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.