Español

Slice Tests, Not a Full Boot

Stop booting your whole app for one controller test. In Spring, a full @SpringBootTest wires every layer — web, services, data, config — which is exactly right for cross-layer behavior and exactly wrong as a default habit. Spring Boot ships purpose-built slice tests that load only the layer under test, and the difference compounds across every test class and every CI run.

What a slice test actually loads

Each @…Test slice annotation does two things: it restricts component scanning to the beans relevant to that layer, and it imports only a small set of auto-configurations instead of all of them.

• @WebMvcTest loads the MVC layer only: @Controller, @ControllerAdvice, converters, filters, interceptors, and WebMvcConfigurer beans. Regular @Component and @ConfigurationProperties beans are not scanned. It auto-configures MockMvc (and MockMvcTester when AssertJ is on the classpath), so you test request handling without a running server. Collaborators get stubbed with @MockitoBean.
• @DataJpaTest loads entities and Spring Data JPA repositories, points them at an embedded test database, gives you a TestEntityManager, and rolls back the transaction at the end of each test by default.
• The same family covers other layers: @JsonTest for serialization, @JdbcTest for raw SQL, @RestClientTest for outbound HTTP clients, @WebFluxTest for reactive controllers, @DataMongoTest for Mongo. The full annotation-to-auto-configuration mapping is in the Spring Boot appendix (see Resources).

Rules of thumb

One constraint worth knowing: you cannot combine multiple @…Test slice annotations on one class. Pick the slice that matches the layer, and pull in extras with the matching @AutoConfigure… annotation if needed.

A controller slice in practice

@WebMvcTest(UserVehicleController.class)
class UserVehicleControllerTests {

    @Autowired
    private MockMvc mvc;

    @MockitoBean
    private UserVehicleService userVehicleService;

    @Test
    void returnsVehicleDetails() throws Exception {
        given(userVehicleService.getVehicleDetails("sboot"))
                .willReturn(new VehicleDetails("Honda", "Civic"));
        mvc.perform(get("/sboot/vehicle"))
                .andExpect(status().isOk())
                .andExpect(content().string("Honda Civic"));
    }
}

No datasource, no service layer, no full context — just the web layer and one stub.

Why this matters for AI-assisted coding

An AI assistant learns your codebase's habits by example. If every existing test is a full-boot @SpringBootTest, the assistant will reach for the heaviest tool for every new test it writes — and your feedback loop degrades one generated file at a time. Seed the repo with slice tests, and state the convention explicitly in your project instructions: "controller tests use @WebMvcTest, repository tests use @DataJpaTest, @SpringBootTest is reserved for cross-layer behavior." Generated tests then follow the fast path by default.

Power-user: exploit context caching

Spring's test framework caches application contexts between tests — a context is built once per unique configuration and reused, with a default cache cap of 32 contexts (LRU-evicted; tune with -Dspring.test.context.cache.maxSize). Two habits maximize hits:

• Keep configurations identical. Every @MockitoBean, profile, or property tweak creates a new context. Standardize your slice setups so dozens of test classes share one cached context.
• Watch the cache in CI. Set org.springframework.test.context.cache to DEBUG to see how many distinct contexts your suite actually builds. A suite that builds 20 contexts is telling you your test configs have drifted.

Resources

• Testing Spring Boot applications — official reference
• Test slice annotations and their auto-configurations — appendix
• @WebMvcTest — API javadoc
• @DataJpaTest — API javadoc
• Context caching — Spring TestContext framework