jenkins the definitive guide

target/surefire-reports/TEST-com.wakaleo.training.tweeter.domain.HamcrestTest.xml

target/surefire-reports/TEST-com.wakaleo.training.tweeter.domain.TagTest.xml

target/surefire-reports/TEST-com.wakaleo.training.tweeter.domain.TweetFeeRangeTest.xm

target/surefire-reports/TEST-com.wakaleo.training.tweeter.domain.TweeterTest.xml

target/surefire-reports/TEST-com.wakaleo.training.tweeter.domain.TweeterUserTest.xml

Maven defines two distinct testing phases: unit tests and integration tests. Unit tests should be fast and
lightweight, providing a large amount of test feedback in as little time as possible. Integration tests are
slower and more cumbersome, and often require the application to be built and deployed to a server
(even an embedded one) to carry out more complete tests. Both these sorts of tests are important, and for
a well-designed Continuous Integration environment, it is important to be able to distinguish between
them. The build should ensure that all of the unit tests are run initially—if a unit test fails, developers
should be notified very quickly. Only if all of the unit tests pass is it worthwhile undertaking the slower
and more heavyweight integration tests.

In Maven, integration tests are executed during the integration-test life cycle phase, which you
can invoke by running mvn integration-test or (more simply) mvn verify. During this phase,
it is easy to configure Maven to start up your web application on an embedded Jetty web server, or to
package and deploy your application to a test server, for example. Your integration tests can then be
executed against the running application. The tricky part however is telling Maven how to distinguish
between your unit tests and your integration tests, so that they will only be executed when a running
version of the application is available.

There are several ways to do this, but at the time of writing there is no official standard approach
used across all Maven projects. One simple strategy is to use naming conventions: all integration tests
might end in “IntegrationTest”, or be placed in a particular package. The following class uses one such
convention:

public class AccountIntegrationTest {

@Test

public void cashWithdrawalShouldDeductSumFromBalance() throws Exception {

Account account = new Account();

account.makeDeposit(100);

account.makeCashWithdraw(60);

assertThat(account.getBalance(), is(40));

}

}

In Maven, tests are configured via the maven-surefire-plugin plugin. To ensure that Maven only
runs these tests during the integration-test phase, you can configure this plugin as shown here:

<project>

...

<build>

<plugins>

<plugin>

<artifactId>maven-surefire-plugin</artifactId>