2
votes

Say I have 10 spring boot test class (annotated with @RunWith(SpringRunner.class) and @SpringBootTest)

Each test needs to launch spring container for like 10 seconds, although the container might do the same init.

So I may need 100 seconds for "mvn test".

Is there a way I can group my 10 test class into 1 suite, and let the container only start once.

So I can:

  • Only run the suite for "mvn test". (with proper naming for individual test class)
  • Optionally run individual test in IDE.
1

1 Answers

1
votes

Spring uses Cache Management to cache the Application Context between tests:

By default, once loaded, the configured ApplicationContext is reused for each test. Thus, the setup cost is incurred only once per test suite, and subsequent test execution is much faster. In this context, the term “test suite” means all tests run in the same JVM — for example, all tests run from an Ant, Maven, or Gradle build for a given project or module. In the unlikely case that a test corrupts the application context and requires reloading (for example, by modifying a bean definition or the state of an application object) the TestContext framework can be configured to reload the configuration and rebuild the application context before executing the next test. (https://docs.spring.io/spring-framework/docs/current/spring-framework-reference/testing.html#integration-testing)

So this mechanism tries to execute your integration tests on an already running Application Context if possible. As you see multiple Application Context launches, this indicates your tests somehow use a different setup e.g. different profiles active, test properties, MockBeans etc.

The Spring documentation provides an overview on which indicators it puts an Application Context in its cache: https://docs.spring.io/spring-framework/docs/current/spring-framework-reference/testing.html#testcontext-ctx-management-caching

If you e.g. don't change any test property for your integration tests, Spring can run all of them on only one Application Context and be extremely efficient.

Another indicator for your current behaviour might be the use of @DirtiesContext which leads to a fresh Application Context after your test executes.