Testing

Spring Boot test slices and test configuration

Q: What are the most common mistakes with Spring Boot test slices and test configuration?

@SpringBootTest for everything. Many differing mock sets that defeat context caching. Relying on rollback and never testing real commits. Using H2 while production runs another database.

A full @SpringBootTest starts the whole application, which is slow.

🔎 Unravel this example Prerequisites (2)

Learn these first

JUnit tests Spring beans and dependency injection

At a glance

Mental model

Testing a car: you can drive the whole car around a track (full application), or put just the engine on a test bench (a slice).

What happens, in order

1@WebMvcTest(OrderController.class) loads only controllers, JSON conversion and security filtersServices are not created, so you provide them as mocks with @MockitoBean (@MockBean before Spring Boot 3.4).
2@DataJpaTest loads entities, repositories and an in-memory or containerised database, wraps each test in a transaction that is rolled back, and gives a TestEntityManager
3@SpringBootTest(webEnvironment = RANDOM_PORT) starts the real server on a random port for end-to-end tests with TestRestTemplate or WebTestClient
4Control the context: @ActiveProfiles("test"), @TestPropertySource, @DynamicPropertySource (inject container ports at runtime) and @Import for extra configuration

Remember

Spring caches application contexts between tests that share the same configuration
@DirtiesContext throws the cached context away after a test: correct for tests that change shared state, expensive if used everywhere
The SpringExtension (JUnit 5) builds a TestContext from the annotations, looks it up in a static cache keyed by the merged configuration, and injects beans into the test instance

Watch out

@SpringBootTest for everythingMany differing mock sets that defeat context cachingRelying on rollback and never testing real commitsUsing H2 while production runs another database

Example (highlighted lines explain it)

@WebMvcTest(OrderController.class)class OrderControllerTest {    @Autowired    MockMvc mvc;    @MockitoBean    OrderService service;    @Test    void returnsNotFoundForUnknownOrder() throws Exception {        when(service.find(99L)).thenReturn(Optional.empty());        mvc.perform(get("/orders/99")).andExpect(status().isNotFound());    }}

line 1 uses WebMvcTest, the core of Spring Boot test slices and test configuration
line 6 uses MockitoBean, the core of Spring Boot test slices and test configuration

Read the full explanation (about 2 min)

A full @SpringBootTest starts the whole application, which is slow. Test slices such as @WebMvcTest or @DataJpaTest start only the part under test (the web layer, the repositories), so tests stay fast and focused.

A mental model

Testing a car: you can drive the whole car around a track (full application), or put just the engine on a test bench (a slice). The bench is quicker, and you can replace the parts you are not testing with dummies.

How it works

@WebMvcTest(OrderController.class) loads only controllers, JSON conversion and security filters. Services are not created, so you provide them as mocks with @MockitoBean (@MockBean before Spring Boot 3.4).

@DataJpaTest loads entities, repositories and an in-memory or containerised database, wraps each test in a transaction that is rolled back, and gives a TestEntityManager.

@SpringBootTest(webEnvironment = RANDOM_PORT) starts the real server on a random port for end-to-end tests with TestRestTemplate or WebTestClient.

Control the context: @ActiveProfiles("test"), @TestPropertySource, @DynamicPropertySource (inject container ports at runtime) and @Import for extra configuration.

Going deeper

Spring caches application contexts between tests that share the same configuration. Every difference (a different @MockitoBean set, a property override) creates a new context, which is why a test suite slows down as variations pile up. Group tests by configuration and prefer slices.

@DirtiesContext throws the cached context away after a test: correct for tests that change shared state, expensive if used everywhere.

@Transactional on a test rolls back at the end, which hides bugs that only show on commit (constraints, flush errors, lazy loading). For those, call flush()/clear() or run without the rollback.

Under the hood

The SpringExtension (JUnit 5) builds a TestContext from the annotations, looks it up in a static cache keyed by the merged configuration, and injects beans into the test instance. Slices work through @TypeExcludeFilters and a restricted list of auto-configurations imported by the slice annotation.

Common mistakes

@SpringBootTest for everything.
Many differing mock sets that defeat context caching.
Relying on rollback and never testing real commits.
Using H2 while production runs another database.

How Unravel recognises it

When you paste code, Unravel looks for these signs of spring boot test slices and test configuration. Spotting them yourself is a good habit when you read unfamiliar code:

Annotations: @WebMvcTest @DataJpaTest @JsonTest @RestClientTest @WebFluxTest @DataMongoTest @JdbcTest @DataRedisTest @AutoConfigureMockMvc @AutoConfigureTestDatabase @AutoConfigureWebTestClient @TestConfiguration @DynamicPropertySource @ActiveProfiles and 13 more
Types: TestEntityManager TestRestTemplate ApplicationContextRunner

Part of a learning path

Testing enterprise code · previous: Advanced Mockito (matchers, captors, static mocks) · next: Testing HTTP endpoints (MockMvc, WebTestClient, REST Assured)

Related concepts

Testing HTTP endpoints (MockMvc, WebTestClient, REST Assured)Testing Testcontainers (real databases and brokers in tests)Testing

Frequently asked questions

What is Spring Boot test slices and test configuration?

What are the most common mistakes with Spring Boot test slices and test configuration?

@SpringBootTest for everything. Many differing mock sets that defeat context caching. Relying on rollback and never testing real commits. Using H2 while production runs another database.

How can I see Spring Boot test slices and test configuration in real code?

Paste your own Java into Unravel and it will point out where spring boot test slices and test configuration appears, explain how it works at the detail level you choose, and draw the flow of the code around it.