Spring Framework 5.0 introduced basic support for running tests in parallel within the same JVM when using the Spring TestContext Framework. In general, this means that most test classes or test methods can be executed in parallel without any changes to the test code or configuration.
Remember that introducing parallelism into a test suite can result in unexpected side effects, unusual logic during program execution, and may cause tests to fail intermittently or randomly. Therefore, the Spring Team offers the following general guidelines regarding cases in which tests should not be run in parallel.
Do not run tests in parallel if the tests:
-
Uses the
@DirtiesContext
annotation support in the Spring Framework. -
Use Spring Boot's
@MockBean
or@SpyBean
annotation support. -
Use support for the
@FixMethodOrder
annotation in JUnit 4, or any test framework feature that is designed to ensure that test methods are executed in a specific order. Note, however, that this does not apply when entire test classes are executed in parallel. -
Changing the state of shared services or systems such as the database, message broker, file system, and others. This applies to both embedded and external systems.
If a parallel test execution fails with an exception stating that the ApplicationContext
for the
current test is no longer active, this usually means that the ApplicationContext
has been removed
from the ContextCache
in another thread.
This may be due to the use of the @DirtiesContext
annotation or due to automatic eviction from
ContextCache
. If the culprit is the @DirtiesContext
annotation, then you need to
either find a way to avoid using @DirtiesContext
or exclude such tests from parallel execution. If
the ContextCache
maximum size has been exceeded, you can increase the maximum cache size. For more
details, see the description in the section on context
caching.
TestContext
implementation provides a copy constructor as described in the
javadoc for TestContext
. The DefaultTestContext
used in Spring provides
such a constructor. However, if you are using a third-party library that provides a custom TestContext
implementation, you will need to ensure that it is suitable for running tests in parallel.