Mockito Strict Stubbing | Java Fresher Interview
Fast recall
Quick revision
Core answer
STRICT_STUBS, Mockito reports stubbings that were never used and can fail early when code calls a stubbed method with different arguments in situations covered by its mismatch detection. It also treats stubbed invocations as verified for no-more-interactions checks. It does not make every unstubbed method throw; ordinary unstubbed calls still use the mock's default answer.Interview-ready guide
Interview answer
Strict stubbing checks the relationship between the setup and the behavior a test actually exercised. If I stub gateway.authorize(100) and the test never uses that stubbing, Mockito can report UnnecessaryStubbingException at the end of the test. In supported mismatch cases it can also point out that production code called the stubbed method with different arguments.
Strict mode does not mean every unstubbed call fails. A normal unstubbed method still returns the mock's configured default answer. The check is about stubbings that were declared but unused or inconsistent.
The JUnit extension, runner, rule, or MockitoSession.finishMocking() completes this validation. I first remove a stale stub or move it into the test that needs it. I use lenient() only for a narrow shared setup that is intentionally optional, because making the whole suite lenient would hide useful feedback.
Mockito Strict Stubbing | Java Fresher Interview
Direct Answer
Strict stubbing validates test setup at the end of the test lifecycle. With STRICT_STUBS, Mockito reports stubbings that were never used and can fail early when code calls a stubbed method with different arguments in situations covered by its mismatch detection. It also treats stubbed invocations as verified for no-more-interactions checks. It does not make every unstubbed method throw; ordinary unstubbed calls still use the mock's default answer.
Code Example
@ExtendWith(MockitoExtension.class)
class PaymentServiceTest {
@Mock
private PaymentGateway gateway;
@InjectMocks
private PaymentService service;
@Test
void strictStubbingCatchesUnusedStub() {
// This stub is never called in the test
when(gateway.authorize(100.0)).thenReturn(true);
// Strict stubbing throws UnnecessaryStubbingException here
// Test calls a different method or different arguments
service.refund(50.0); // doesn't use the stub above
}
@Test
void strictStubbingCatchesWrongArguments() {
when(gateway.authorize(100.0)).thenReturn(true); // stubbed with 100.0
service.processPayment(200.0); // calls authorize(200.0) - different argument!
// Strict stubbing detects the mismatch and fails the test
}
}
Common Mistakes & Pitfalls
- Disabling strict stubs when seeing UnnecessaryStubbingException: Adding lenient() or switching to lenient mode instead of fixing the actual problem—removing the unused stub or adding the missing assertion. The exception is telling you the test is broken; silencing it just hides technical debt.
- Declaring stubs in @BeforeEach for optional scenarios: Setting up stubs that only some tests need in a shared setup method—strict stubbing fails tests that don't use those stubs. Move stubs into individual test methods instead.
- Copy-pasting test setup without cleanup: Duplicating a test method, changing one line, but leaving all the original stubs intact—strict stubbing catches the now-irrelevant stubs that the new test doesn't exercise.
Check your understanding
Answer these without looking back at the article.
- How do you make a specific stub lenient in strict mode?
- What is UnnecessaryStubbingException?
- How do you reset Mockito strictness globally?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.