Mocking vs Stubbing Java | Fresher Interview
Fast recall
Quick revision
Core answer
Interview-ready guide
Interview answer
Stubbing and mocking are related but different.
Stubbing is when you configure a fake object to return a specific value. You use when-thenReturn to set up what it gives back.
For example, when repository dot find by I-D returns a user object. That's stubbing—you're controlling the answer. Mocking in the strict sense is about verifying that a method was called.
You use verify to assert the interaction happened.
For example, verify repository dot save was called with this user. That's mocking—you're checking behavior, not return values. The confusing part is that Mockito blurs this distinction.
A Mockito mock can do both—you stub its return values and verify its calls. So people casually say mock when they mean stub, and that's fine in conversation. But knowing the difference matters in interviews.
Stubbing is about queries—methods that return data. Mocking is about commands—methods with side effects. If you're testing that a service calculates a total correctly, you stub the repository.
If you're testing that the service sends an email, you verify the email service was called.
In practice, you often do both in one test. Stub the dependencies to return test data, then verify the subject called the right methods. The key thing is: stub focuses on what came back, verify focuses on what was called.
Mocking vs Stubbing Java | Fresher Interview
Direct Answer
Stubbing configures a fake to return a specific value using when-thenReturn. Mocking in the verification sense asserts that a method was called using verify. Mockito objects are both—they can stub return values AND verify interactions. The terms are often used interchangeably in casual speech.
Code Example
@ExtendWith(MockitoExtension.class)
class OrderServiceTest {
@Mock OrderRepository repo;
@InjectMocks OrderService service;
@Test
void stubAndVerify() {
// STUB: program a return value (state-based)
when(repo.findById(1L)).thenReturn(Optional.of(new Order(1L, 100.0)));
service.archive(1L);
// MOCK (verification): assert an interaction happened (behaviour-based)
verify(repo).deleteById(1L);
}
}
Common Mistakes & Pitfalls
- Using mock to mean stub: Freshers say 'I mocked the return value' when they mean 'I stubbed it.' Technically, mocking is verification, not return configuration. This matters in code reviews where seniors expect precise vocabulary.
- Over-verifying: Beginners verify every single method call, including internal details that aren't part of the contract. This makes tests brittle—refactoring the implementation breaks tests even when behavior is unchanged.
- Not verifying side effects: When testing a method that should send an email or publish an event, freshers only stub but never verify the call happened. The test passes even if the side effect is removed from production code.
Check your understanding
Answer these without looking back at the article.
- What is a spy in Mockito?
- What is the difference between state verification and behavior verification?
- What is Gerard Meszaros's test double taxonomy?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.