Verifying a Method Was Never Called
Fast recall
Quick revision
Core answer
Interview-ready guide
Interview answer
To verify a method was never called, I use verify mock comma never dot method.
This is negative verification — asserting that something didn't happen. It's just as important as verifying positive interactions because it catches unintended side effects.
For example, if an order fails validation, I want to make sure paymentGateway dot charge was never called, not just that the validation error was returned. The verify mock comma never form checks that the specific method with those specific arguments wasn't invoked. If I want to ensure the method wasn't called with any arguments, I'd use verify mock comma never dot method any.
There's also verifyNoInteractions mock, which is broader — it asserts that no methods at all were called on the mock. I'd use that when the entire mock should be untouched, like a notification service in dry-run mode.
A common mistake freshers make is not verifying negative cases. They test the happy path and check that methods were called, but they don't check that unsafe methods weren't called in error paths. For risky operations like delete or charge or send, you should explicitly verify they didn't happen when they shouldn't, because assuming the absence of a call isn't enough.
Verifying a Method Was Never Called
Direct Answer
Use verify(mock, never()).method() to assert a method was never invoked, or verifyNoInteractions(mock) to assert no methods on the mock were called at all.
Code Example
@ExtendWith(MockitoExtension.class)
class OrderServiceTest {
@Mock
private PaymentGateway paymentGateway;
@Mock
private EmailService emailService;
@InjectMocks
private OrderService orderService;
@Test
void shouldNotChargePaymentWhenOrderIsInvalid() {
var invalidOrder = new Order(null, "Laptop", -100.00); // negative price
var result = orderService.createOrder(invalidOrder);
assertThat(result.isSuccess()).isFalse();
verify(paymentGateway, never()).charge(any()); // charge() should not have been called
}
@Test
void shouldNotSendNotificationInDryRunMode() {
var order = new Order(5L, "Phone", 800.00);
orderService.createOrderDryRun(order); // dry run mode
verifyNoInteractions(emailService); // no methods on emailService should have been called
}
}
Common Mistakes & Pitfalls
- Not verifying negative cases: Freshers focus on happy path verification — checking that methods were called — but skip verifying that unsafe methods were not called in error cases. For example, testing that validation fails but not verifying that save() wasn't called afterward.
- Confusing never() and times(0): They're equivalent — verify mock comma never dot method and verify mock comma times 0 dot method do the same thing — but never is clearer intent.
- Using verifyNoInteractions when you mean never: verifyNoInteractions checks that the entire mock was untouched. If you only care that one specific method wasn't called, use verify mock comma never dot specificMethod.
- Forgetting argument matchers: verify mock comma never dot delete userOne only checks that delete with that exact user wasn't called. If you want to ensure delete wasn't called with any argument, use verify mock comma never dot delete any.
Check your understanding
Answer these without looking back at the article.
- What is the difference between verifyNoInteractions() and verifyNoMoreInteractions()?
- When would you combine verify(never()) with a conditional test?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.