Splitting Unit and Integration Tests Using Maven and Surefire Plugin
Learn how to split unit and integration tests using the Maven and Surefire plugin.
Join the DZone community and get the full member experience.
Join For FreeIntroduction
Generally, when you write Java unit tests, you stub data or mock the target class dependencies. This allows you to verify the business logic in an environment where you don’t depend on third-party services.
Integration tests also play an important role in the CI/CD process to release software frequently and safely. As I have mentioned before, the integration testing goal is to verify that interaction between different parts of the system works well. Examples of such interactions are:
- Connecting to an RDBMS to retrieve or persist data
- Consuming a message from a broker
- Sending an email
- Processing an upstream response
In large enterprise applications development, with hundreds of unit and integration tests, the test suites take a considerable amount of time to complete, typically hours.
Wouldn’t it make sense to split the tests by their purpose and execution speed? It would be beneficial for an organization to get quicker feedback when tests fail.
It would then be advisable to implement a fail-fast approach and break the build process when unit tests fail. This post covers configuring Maven’s maven-surefire-plugin to split running unit and integration tests.
Requirements
- Java 7+
- Maven 3.2+
The REST Controller, Plus Unit and Integration Tests
Assuming you have generated a Spring Boot 2 application using Spring Initializr from the command line or via your preferred IDE, let’s add a simple REST controller DemoController.java:
@RestController
@RequestMapping(value = "/api/entities")
public class DemoController {
...
@GetMapping(value = "/{id}")
public ResponseEntity<String> findEntity(@PathVariable String id) {
String entity = this.someBusinessService.findEntity(id);
return new ResponseEntity<>(entity, HttpStatus.OK);
}
}Let’s now add the unit and integration test classes meant to run during Maven’s test and integration-test phases.
DemoControllerTest.java:
package com.asimio.demo.rest;
...
@RunWith(MockitoJUnitRunner.class)
public class DemoControllerTest {
@Mock
private SomeBusinessService mockSomeBusinessService;
...
@Test
public void shouldRetrieveAnEntity() {
// Given
Mockito.when(this.mockSomeBusinessService.findEntity("blah")).thenReturn("meh");
// When
ResponseEntity<String> actualResponse = this.demoController.findEntity("blah");
// Then
Assert.assertThat(actualResponse.getStatusCode(), Matchers.equalTo(HttpStatus.OK));
Assert.assertThat(actualResponse.getBody(), Matchers.equalTo("meh"));
}
}DemoControllerIT.java:
package com.asimio.demo.rest;
...
@RunWith(SpringRunner.class)
@ContextConfiguration(classes = { Application.class })
@SpringBootTest(webEnvironment = WebEnvironment.RANDOM_PORT)
public class DemoControllerIT {
...
@Test
public void shouldRetrieveAnEventById() {
String body = RestAssured.
given().
accept(ContentType.JSON).
when().
get("/api/entities/blah").
then().
statusCode(HttpStatus.SC_OK).
contentType(ContentType.JSON).
extract().asString();
Assert.assertThat(body, Matchers.equalTo("Retrieved entity with id: blah"));
}
}Note: Unit test classes are suffixed with test and integration test classes with IT. I have kept them in the same package for simplicity, but it would be a good practice to place unit and integration tests in different folders.
Configuring the Maven-Surefire-Plugin
There are now two unit test classes, DemoControllerTest.java and DefaultSomeBusinessServiceTest, and two integration tests, DemoControllerIT.java and ApplicationTests. Let’s configure maven-surefire-plugin in pom.xml to split running them in the test and integration-test phases:
...
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId> <!-- surefire plugin version managed by Spring Boot -->
<configuration>
<skipTests>true</skipTests>
</configuration>
<executions>
<execution>
<id>unit-tests</id>
<phase>test</phase>
<goals>
<goal>test</goal>
</goals>
<configuration>
<skipTests>false</skipTests>
<includes>
<include>**/*Test.java</include>
</includes>
</configuration>
</execution>
<execution>
<id>integration-tests</id>
<phase>integration-test</phase>
<goals>
<goal>test</goal>
</goals>
<configuration>
<skipTests>false</skipTests>
<includes>
<include>**/*IT.*</include>
<include>**/*Tests.*</include>
</includes>
</configuration>
</execution>
</executions>
</plugin>Running the Tests and Building the Artifacts
A Successful Build
Let’s first run and analyze a successful build:
mvn clean verify
...
[INFO] --- maven-surefire-plugin:2.22.1:test (default-test) @ springboot2-split-unit-integration-tests ---
[INFO] Tests are skipped.
[INFO]
[INFO] --- maven-surefire-plugin:2.22.1:test (unit-tests) @ springboot2-split-unit-integration-tests ---
[INFO]
[INFO] -------------------------------------------------------
[INFO] T E S T S
[INFO] -------------------------------------------------------
[INFO] Running com.asimio.demo.rest.DemoControllerTest
[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.647 s - in com.asimio.demo.rest.DemoControllerTest
[INFO] Running com.asimio.demo.service.DefaultSomeBusinessServiceTest
[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.001 s - in com.asimio.demo.service.DefaultSomeBusinessServiceTest
[INFO]
[INFO] Results:
[INFO]
[INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0
...
[INFO] --- maven-jar-plugin:3.1.1:jar (default-jar) @ springboot2-split-unit-integration-tests ---
[INFO] Building jar: /Users/ootero/Projects/bitbucket.org/springboot2-split-unit-integration-tests/target/springboot2-split-unit-integration-tests.jar
[INFO]
[INFO] --- spring-boot-maven-plugin:2.1.4.RELEASE:repackage (repackage) @ springboot2-split-unit-integration-tests ---
[INFO] Replacing main artifact with repackaged archive
[INFO]
[INFO] --- maven-surefire-plugin:2.22.1:test (integration-tests) @ springboot2-split-unit-integration-tests ---
[INFO]
[INFO] -------------------------------------------------------
[INFO] T E S T S
[INFO] -------------------------------------------------------
[INFO] Running com.asimio.demo.ApplicationTests
...
[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 5.151 s - in com.asimio.demo.ApplicationTests
[INFO] Running com.asimio.demo.rest.DemoControllerIT
...
[INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
...The verify phase also executes the test, package, and integration-test phases among others. Read more at Maven’s Build Default Lifecycle Reference.
During the test phase execution, maven-surefire-plugin’s default-test execution was skipped. That’s the result of setting skipTests to true in pom.xml (lines 5 through 7). The unit-tests execution ran one test in each test-suffixed class without any failures.
Next, the package phase ran and built the main artifact. Then, the spring-boot-maven-plugin replaced the main jar with an uber-jar containing all the dependencies this application needs.
The integration-test phase ran right after. This time, Maven runs test methods found in DemoControllerIT.java and ApplicationTests classes, ending in a successful build.
Let’s take a look at Maven’s target folder:
ls -1a target/ target/surefire-reports/
target/:
.
..
classes
generated-sources
generated-test-sources
maven-archiver
maven-status
springboot2-split-unit-integration-tests.jar
springboot2-split-unit-integration-tests.jar.original
surefire-reports
test-classes
target/surefire-reports/:
.
..
TEST-com.asimio.demo.ApplicationTests.xml
TEST-com.asimio.demo.rest.DemoControllerIT.xml
TEST-com.asimio.demo.rest.DemoControllerTest.xml
TEST-com.asimio.demo.service.DefaultSomeBusinessServiceTest.xml
com.asimio.demo.ApplicationTests.txt
com.asimio.demo.rest.DemoControllerIT.txt
com.asimio.demo.rest.DemoControllerTest.txt
com.asimio.demo.service.DefaultSomeBusinessServiceTest.txtNotice the Maven Surefire reports. Stay tuned; I’ll cover uploading these reports and code coverage using JaCoCo to SonarQube in another post — without running the tests twice, as I have seen happening when using Cobertura.
When Unit Tests Fail
Let’s cause a unit test to fail in DemoControllerTest.java as a second scenario:
// Then
Assert.assertThat(actualResponse.getStatusCode(), Matchers.equalTo(HttpStatus.OK));
- Assert.assertThat(actualResponse.getBody(), Matchers.equalTo("meh"));
+ Assert.assertThat(actualResponse.getBody(), Matchers.equalTo("should-fail"));And attempting to build again:
mvn clean verify
...
[INFO] --- maven-surefire-plugin:2.22.1:test (unit-tests) @ springboot2-split-unit-integration-tests ---
[INFO]
[INFO] -------------------------------------------------------
[INFO] T E S T S
[INFO] -------------------------------------------------------
[INFO] Running com.asimio.demo.rest.DemoControllerTest
[ERROR] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.857 s <<< FAILURE! - in com.asimio.demo.rest.DemoControllerTest
[ERROR] shouldRetrieveAnEntity(com.asimio.demo.rest.DemoControllerTest) Time elapsed: 0.113 s <<< FAILURE!
java.lang.AssertionError:
Expected: "should-fail"
but: was "meh"
at com.asimio.demo.rest.DemoControllerTest.shouldRetrieveAnEntity(DemoControllerTest.java:37)
[INFO] Running com.asimio.demo.service.DefaultSomeBusinessServiceTest
[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 s - in com.asimio.demo.service.DefaultSomeBusinessServiceTest
...
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
...The test phase failed and prevented the build from running the following phases. It’s a fail-fast approach. The artifact wasn’t built and integration tests didn’t run. Read more at Maven’s Build Default Lifecycle Reference.
Conclusion
It’s a good practice to add unit and integration tests when developing enterprise applications. While a unit test suite should run in the order of milliseconds or seconds, integration tests take minutes, if not hours.
Reseeding data, network traffic, starting Docker containers before executing a test or test suite will slow down your integration tests. It would make sense to split them when your test suites are large enough to have faster feedback. Why? With a shorter build cycle, you get quicker feedback, allowing you to act faster, increasing your productivity.
Thanks for reading and sharing. If you found this post helpful and would like to receive updates when content like this gets published, sign up to the newsletter.
Source Code
Accompanying source code for this blog post can be found here.
References
Published at DZone with permission of Orlando Otero, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
Comments