Unit vs Integration Test Structure
Fast recall
Quick revision
Core answer
Whether the candidate can write or recognize both test types and knows the annotation differences from memory.
Using @SpringBootTest on a service unit test, wasting context startup time and calling it a unit test.
Show both test structures from memory with correct imports and explain why each annotation is chosen for its purpose—demonstrate you've written both types in real projects.
Interview-ready guide
Interview answer
A typical unit test constructs one subject and supplies controlled collaborators; MockitoExtension with @Mock is a common convenience. An integration test names the real boundary: WebMvcTest with MockMvc for MVC behavior, DataJpaTest for JPA behavior, or SpringBootTest for broader Boot wiring. It may use @Autowired for context beans and can still mock an out-of-scope remote dependency. I identify the test by what it truly exercises, not just by seeing Mock, Autowired, or SpringBootTest in the file.
Unit vs Integration Test Structure
Direct Answer
A typical unit test constructs the subject directly and may use MockitoExtension with @Mock for controlled collaborators. An integration test selects the real boundary it needs: for example @WebMvcTest for MVC, @DataJpaTest for JPA, or @SpringBootTest for broader Boot wiring. The annotations suggest the setup, but the exercised boundary determines the test type.
Common Mistakes & Pitfalls
Using @SpringBootTest on a service unit test, wasting context startup time and calling it a unit test.
Check your understanding
Answer these without looking back at the article.
- What is the difference between @Mock and @MockBean?
- When would you use @Spy instead of @Mock?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.