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.
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:
Let’s now add the unit and integration test classes meant to run during Maven’s test and integration-test phases.
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:
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:
Notice 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.
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.
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.
Accompanying source code for this blog post can be found here.