Integration Testing in Spring Boot — @SpringBootTest, @DataJpaTest, @WebMvcTest
Fast recall
Quick revision
Core answer
Whether the candidate understands the integration testing strategy in Spring Boot and can explain when each test slice is appropriate.
Using @SpringBootTest for every integration test instead of targeted slices, leading to slow test suites.
Explain context caching, the relationship between @MockBean and cache invalidation, and how to structure integration tests for maximum cache reuse.
Interview-ready guide
Interview answer
@SpringBootTest loads the full application context — every bean, every auto-configuration. It gives maximum fidelity but takes 10-30 seconds to start. Test slices like @WebMvcTest and @DataJpaTest load only the relevant portion, starting in under 2 seconds.
@WebMvcTest(UserController.class) loads just the controller layer — no services, no repositories, no database. You mock dependencies with @MockBean. @DataJpaTest loads JPA repositories with an embedded database — no controllers.
The rule: use the narrowest slice that covers what you're testing. Reserve @SpringBootTest for smoke tests and cross-cutting integration tests — maybe 10-20% of your suite. The rest should use slices.
One thing that trips people up: Spring caches contexts, but each unique @MockBean combination creates a new cache key. Minimizing distinct mock combinations across test classes keeps caching effective and the suite fast.
Integration Testing in Spring Boot — @SpringBootTest, @DataJpaTest, @WebMvcTest
Direct Answer
Spring Boot integration tests verify that components work together with real infrastructure. @SpringBootTest loads the full context; @WebMvcTest, @DataJpaTest load targeted slices for faster, focused tests.
Common Mistakes & Pitfalls
Using @SpringBootTest for every integration test instead of targeted slices, leading to slow test suites.
Related interview prep categories
1Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.