Isolating integration tests and mocking dependencies with Spring Boot

Of course, all those classes are stored in our test source folder (usually src/test/java) since they are not required for production.

Let us have a look again at the annotations:

• @RunWith: The test will use the Spring Junit runner who will take care of creating the Spring context for us.
• @WebIntegrationTest: Tells Spring that this is an integration test running a web application, otherwise by default Spring will not run an HTTP server in test mode. We also set the server.port to a value of 0 so that Spring Boot choose a random port for the HTTP server to listen to. This allows to have several tests running in parallel, or to have another version of the application running in the background.
• @SpringApplicationConfiguration: We tell Spring where it will find the DelayedWebServerConfiguration class we created before.
• @ActiveProfiles: Enables the restTemplateTimeout profile, otherwise the Controller and the Configuration will be filtered out.

We now have an integration test running with a limited set of dependencies instead of the whole application. What if we wanted to go further and add mocks into the game? This may be required when a dependency does not have a dev environment or that it is too complicated to call from a developer's workstation. In that case, we can add those mocks to the Configuration class and they will be injected into the test's Spring context.

Here is a Configuration example where we inject a custom CustomerService mocked by Mockito instead of the default one:

@Profile("validationTests")
@Configuration
@EnableAutoConfiguration(
    exclude = {DataSourceAutoConfiguration.class, HibernateJpaAutoConfiguration.class})
@ComponentScan(basePackages = {"my.application.controller",
    "my.application.actions"})
public class ValidationEndToEndConfiguration {
    @Bean
  public CustomerService customerService() {
    return Mockito.mock(CustomerService.class);
  }
}

With this approach, we can make our integration tests more resilient. For slow or unreliable dependencies, it is more efficient to have the developers run their integration tests against a mocked version. However, do not forget that in the end your application will have to integrate with the real system, not the mocked one. For this reason, it makes sense to have the continuous integration server run the tests against the real system at the very least every day.