How to verify that a specific method was not called using Mockito?
Interview Questions practice on Codemia
Over 8,000 real interview questions from top companies, searchable by company and role.
Introduction
To verify that a specific method was not called using Mockito, use verify(mock, never()).methodName(args). The never() verification mode is the most direct and readable way to assert non-invocation. Mockito also provides verifyNoInteractions() for asserting that a mock had zero interactions of any kind, and verifyNoMoreInteractions() for asserting that no unverified interactions remain. Each serves a different testing intent, and choosing the right one produces tests that clearly communicate what behavior is being asserted.
verify with never(): Assert a Specific Method Was Not Called
never() is the standard approach when you need to verify that one particular method was not invoked:
never() is equivalent to times(0) but reads more naturally. Both produce identical behavior:
Prefer never() because it communicates intent more clearly. "This method should never be called" reads better than "this method should be called zero times."
Verifying with Specific Arguments
You can assert that a method was not called with specific arguments while allowing calls with other arguments:
verifyNoInteractions(): Assert Zero Activity on a Mock
Use verifyNoInteractions() when a mock should not have been touched at all:
This is stronger than verify(mock, never()).someMethod() because it catches calls to any method on the mock, not just the one you specified. It is the right choice when the entire dependency should be bypassed.
You can pass multiple mocks:
verifyNoMoreInteractions(): Assert No Unverified Calls
Use verifyNoMoreInteractions() after verifying expected interactions to ensure nothing else happened:
Without the verifyNoMoreInteractions() call, you would not catch unexpected side effects like an extra database write or an unintended audit log call.
Comparison of Verification Methods
| Method | Scope | Use Case | Fails When |
verify(mock, never()).method() | Single method | Specific method must not be called | That specific method was called |
verifyNoInteractions(mock) | Entire mock | Mock should be completely unused | Any method was called on the mock |
verifyNoMoreInteractions(mock) | Unverified calls | No surprise calls beyond what was verified | Unverified method calls exist |
verify(mock, times(0)).method() | Single method | Same as never() (less readable) | That specific method was called |
Practical Examples
Testing Conditional Logic
Testing Error Paths
Testing with Argument Captors
Sometimes you need to verify a method was not called while also verifying what it was called with in other scenarios:
Using with @MockBean in Spring Boot Tests
In Spring Boot integration tests, verification works the same way with @MockBean:
InOrder Verification with never()
When the order of interactions matters, combine InOrder with never():
Common Pitfalls
- Using verifyNoMoreInteractions as a default in every test. This makes tests brittle. If the implementation adds a harmless toString() or logging call, every test breaks. Reserve
verifyNoMoreInteractions()for tests where unexpected interactions are genuinely concerning. - Verifying non-interaction on a real object instead of a mock. Mockito verification only works on mock objects. Calling
verify()on a real instance throwsNotAMockException. Ensure the object under verification was created withmock()or@Mock. - Forgetting argument matchers when using never().
verify(mock, never()).method("specific")only checks that the method was never called with that exact argument. It does not catch calls with different arguments. UseanyString()orany()for broader assertions. - Confusing verifyNoInteractions with verifyNoMoreInteractions.
verifyNoInteractionsfails if any method was called at all.verifyNoMoreInteractionsfails only for calls that have not been explicitly verified. Mixing them up produces tests that either over-constrain or under-constrain behavior. - Not resetting mocks between tests. In test classes with shared mock instances, interactions from one test method leak into another. Use
@BeforeEachwithreset(mock)or, better, create fresh mocks per test. - Over-mocking. Verifying that ten methods were never called usually means the test is verifying implementation details rather than behavior. Focus on the one or two non-interactions that represent actual business rules.
Summary
- Use
verify(mock, never()).method()to assert a specific method was not called. This is the most common and readable approach. - Use
verifyNoInteractions(mock)when the entire mock should have been completely unused. - Use
verifyNoMoreInteractions(mock)after verifying expected calls to catch unintended side effects. - Prefer
never()overtimes(0)for readability. - Combine with argument matchers (
any(),eq()) to control how broadly the non-interaction assertion applies. - Avoid overusing
verifyNoMoreInteractions()as a blanket assertion, as it creates brittle tests that break on harmless implementation changes.
Related reading
- How to view autoconfigure log output during spring boot tests integration tests
- How to view the list of compile errors in IntelliJ?
- How to view the SQL queries issued by JPA?
- How to wait for all threads to finish, using ExecutorService?
- How to verify that method was NOT called in Moq?
- How to wait for async mounted of Vue component to finish before continuing with testing
- How to wait for all threads to finish, using ExecutorService?
- How to write a proper global error handler with Spring MVC / Spring Boot

OOD Fundamentals
Master object-oriented design from first principles, SOLID, design patterns, and classic interview problems with hands-on coding.
View the courseTrack what you have practised
A free account saves your progress, solutions and study plan across every problem on Codemia.
Interview Questions practice on Codemia
Over 8,000 real interview questions from top companies, searchable by company and role.