Message-ID: <2123808127.2077.1432583087473.JavaMail.firstname.lastname@example.org> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_2076_945520040.1432583087473" ------=_Part_2076_945520040.1432583087473 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
"The Failsafe Plugin is designed to run integration tests while= the Surefire Plugins is designed to run unit tests." - http://maven.apache.org/plugins/maven-failsafe-pl= ugin/
See below for the Failsafe sect= ion.
However, some people are using Surefire for integration testing - not le= ast because Failsafe only came along some time after Surefire ...
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.
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.
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.
If for some reason you can't put the integration tests in a separate mod= ule, here are some ideas.
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.
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=
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= .
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.
You will then have the following lifecycle bindings
Plugin execution goal
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.=
This allows you to set-up your integration test environment during the <=
This allows you to set-up your integration test environment during the <= strong>pre-integration-testphase, run your integration tests duri= ng the integration-test phase, cleanly tear-down = your integration test environment during the post-integration-test<= /strong> phase before finally checking the integration test results and fai= ling the build if necessary. Here is an example using jetty for hosting an = integration test environment:
Rumor has it that a future version of Maven will support something like = src/it/java in the integration-test phase, in addition to src/test/java in = the test phase.