However, some people are using Surefire for integration testing - not le=
ast because Failsafe only came along some time after Surefire ...

Put your Integration tests in a separate module

Better Builds With Maven describes a single example module containing on=
ly integration tests. In the case of a multi-module "reactor" pro=
ject, where each module may need some integration testing, you have some ch=
oices available to you.

Cre=
ate Multiple Integration Test POMs

You can, if you wish, create multiple integration test modules, one for =
each source module in your project. For example, if you've got two child pr=
ojects "foo" and "bar", you could create a "foo-in=
tegration-test" module and a "bar-integration-test" module t=
o test "foo" and "bar" respectively.

The advantage of doing it this way is that it's very clear which integra=
tion tests belong to which project. It's also easy for project owners to kn=
ow which integration tests they're responsible for. The big drawback here i=
s that you've just doubled the number of POM files in your reactor, which c=
an be difficult to manage. Each project will need to be separately referenc=
ed in the root POM.

Put all Integration Tests into One Big Module

This is obviously much simpler to wire up in a POM file; simplicity is a=
virtue in project management.

The disadvantage of doing it this way is that it tends to separate the i=
ntegration tests from the code they're attempting to test. As a result, you=
may find that no one "owns" the integration tests; typically you=
'll have some one person whose job it is to analyze the integration tests a=
nd find bugs. QA is hard, but it's even harder when it's unclear who "=
owns" test failures.

Alternatives to Isolating the Integration Tests

If for some reason you can't put the integration tests in a separate mod=
ule, here are some ideas.

Integration Test=
s Only

If you have only integration tests in the same module a=
s your webapp, you can configure Surefire to skip the test phase, then run =
in the integration-test phase. See this page.

Both Unit and Integration Tests in the Same Module

If you need to run both unit and integration tests in the same module, i=
t's possible, just not very pretty.

There is only one testSourceDirectory per module, so all of your test cl=
asses must reside in one directory structure, usually src/test/java.

In the 'test' phase, configure Surefire to exclude the tests in (for exa=
mple) **/systest/**=
.

Bind another execution of maven-surefire-plugin to the integration-test =
phase, and reverse the exclusion pattern.

You can see an example of this in the Shale Usecases example app pom.xml file=
.

Using the Maven Failsafe Plugin to run Integration Tests

The Maven Failsafe Plugin is a fork=
of the Maven Surefire Plugin designed to help when running integration tes=
ts.

If you use this approach, you keep all your tests for a module in the te=
stSourceDirectory, e.g. src/test/java. By default the Failsafe Maven Plugin=
looks for integration tests matching the patterns */IT.ja=
va, **/IT.java and */*ITCase.java. You will notice t=
hat these bindings do not overlap with the default surefire bindings. =
To use the Maven Failsafe Plugin you need to add the following to your pom.xml =
file.

The advantage to using the Maven Failsafe Plugin is that it will not sto=
p the build during the integration-test phase if there are=
test failures. The recommendation is that you do not directly invoke=
the pre-integration-test, integration-test or post-integration-test phases but that instead you ru=
n integration tests by specifying the verify phase, e.g.=
p>

=20

mvn verify

=20

This allows you to set-up your integration test environment during the <=
strong>pre-integration-test