Introduction

Spring Boot test configuration is mainly about loading the right amount of application context for the test you are writing. The fastest and cleanest tests usually avoid loading the whole app unless they truly need it. Spring Boot gives you several layers of test configuration, from focused test slices to full integration contexts.

Start with the Smallest Test Context

A common mistake is using @SpringBootTest for every test class. That works, but it is often slow and unnecessary.

Use smaller slices when possible:

• '@WebMvcTest for controller-layer tests'
• '@DataJpaTest for JPA repositories'
• '@JsonTest for JSON serialization'
• '@RestClientTest for REST client components'

Example for a controller test:

1import org.junit.jupiter.api.Test;
2import org.springframework.beans.factory.annotation.Autowired;
3import org.springframework.boot.test.autoconfigure.web.servlet.WebMvcTest;
4import org.springframework.boot.test.mock.mockito.MockBean;
5import org.springframework.test.web.servlet.MockMvc;
6
7import static org.mockito.BDDMockito.given;
8import static org.springframework.test.web.servlet.request.MockMvcRequestBuilders.get;
9import static org.springframework.test.web.servlet.result.MockMvcResultMatchers.content;
10import static org.springframework.test.web.servlet.result.MockMvcResultMatchers.status;
11
12@WebMvcTest(UserController.class)
13class UserControllerTest {
14
15    @Autowired
16    MockMvc mockMvc;
17
18    @MockBean
19    UserService userService;
20
21    @Test
22    void returnsUserName() throws Exception {
23        given(userService.getName(1L)).willReturn("Ada");
24
25        mockMvc.perform(get("/users/1"))
26                .andExpect(status().isOk())
27                .andExpect(content().string("Ada"));
28    }
29}

This loads only the web layer, not the whole application.

Use @SpringBootTest for Full Integration

When the test really needs the full application context, use @SpringBootTest.

1import org.junit.jupiter.api.Test;
2import org.springframework.boot.test.context.SpringBootTest;
3
4@SpringBootTest
5class ApplicationContextTest {
6
7    @Test
8    void contextLoads() {
9    }
10}

This is appropriate for:

• startup wiring checks
• cross-layer integration tests
• tests that need the real Boot configuration

Just do not use it as the default for every test class.

Add Test-Only Beans with @TestConfiguration

When you need a bean only in tests, @TestConfiguration is a clean way to add or override it.

1import org.springframework.boot.test.context.TestConfiguration;
2import org.springframework.context.annotation.Bean;
3
4@TestConfiguration
5class TestConfig {
6    @Bean
7    ClockProvider clockProvider() {
8        return () -> "2025-01-01T00:00:00Z";
9    }
10}

Then import it into the test:

1import org.springframework.context.annotation.Import;
2
3@SpringBootTest
4@Import(TestConfig.class)
5class OrderServiceTest {
6}

This keeps test wiring explicit instead of smuggling test behavior into production config classes.

Override Properties for Tests

Spring Boot also makes property overrides easy.

1@SpringBootTest(properties = {
2    "feature.x.enabled=false",
3    "service.timeout=100"
4})
5class FeatureToggleTest {
6}

For broader test environments, @ActiveProfiles("test") plus application-test.properties is often cleaner than repeating inline properties everywhere.

1import org.springframework.test.context.ActiveProfiles;
2
3@SpringBootTest
4@ActiveProfiles("test")
5class BillingServiceTest {
6}

That is a strong pattern when many tests share the same test environment setup.

For infrastructure-style integration tests, newer Spring patterns such as @DynamicPropertySource are also useful when container ports or ephemeral service URLs are not known ahead of time. That keeps the test configuration dynamic without hardcoding values into static property files.

Mock at the Boundary You Actually Need

@MockBean is powerful, but overusing it can turn integration tests into brittle unit tests with a large application context. Mock only the dependencies that the current test truly needs to isolate.

If nearly every bean is mocked, that is a sign the test should probably be a plain unit test without Spring at all.

Keep Test Layers Intentional

A good rule of thumb is to decide first what the test is proving:

• business logic only: plain unit test, no Spring context
• controller mapping and HTTP behavior: @WebMvcTest
• repository behavior: @DataJpaTest
• full wiring across layers: @SpringBootTest

That one decision usually determines most of the test configuration. Once the scope is explicit, the annotations become much easier to choose consistently.

Common Pitfalls

• Using @SpringBootTest for every test and paying unnecessary startup cost.
• Loading a test slice and then expecting beans from unrelated layers to be present.
• Hiding test-only behavior in production configuration instead of @TestConfiguration.
• Overusing @MockBean until the test no longer resembles the real application wiring.
• Mixing many property override styles without a clear convention.

Summary

• Choose the smallest Spring Boot test context that matches the test goal.
• Use test slices such as @WebMvcTest or @DataJpaTest when full context is unnecessary.
• Use @SpringBootTest for real integration cases, not as the default for everything.
• Add test-only beans with @TestConfiguration and override properties deliberately.
• Good Spring Boot test configuration is mostly about reducing unnecessary context while keeping intent clear.