How to verify that a specific method was not called using Mockito?

The thorough guide on absence verification

Below is a holistic approach explaining the different tools Mockito provides for checking method non-invocations and when to use them.

Checking zero interactions with never()

For zero invocations of a method, the never() matcher is your friend:

verify(mock, never()).method();


By using never(), your intention becomes clear as crystal to any reader.

times(0) - an alternative to never()

Apart from never(), Mockito provides times(0) for the same purpose:

verify(mock, times(0)).method();


Though times(0) and never() lead to the same outcome, the latter is preferred for its clearer semantics.

When no interaction at all is an absolute priority

For stricter checks where your mock object must remain untouched, Mockito offers verifyNoInteractions():

verifyNoInteractions(mock);


This ensures your mock was not involved in any method calls.

Boosting readability with static imports

Static imports let you write cleaner, more readable test code:

import static org.mockito.Mockito.*;


You can now write verify(mock).method(); instead of Mockito.verify(mock).method(); — a small but meaningful improvement.

Post-test checkups with verifyNoMoreInteractions()

We can carry out checks after each test with JUnit's @After or @AfterEach:

@After
public void verifyMocks() {
    verifyNoMoreInteractions(mock);
}


The above method ensures each method interaction was verified, leaving no stone unturned.

Moving past the deprecated verifyZeroInteractions()

Though verifyZeroInteractions() may still be in use in older codebases, it's deprecated.

verifyNoInteractions(mock);


verifyNoInteractions() is the modern replacement for the same functionality.

Keeping checks uniform

For simplicity and consistency, keep your invocation checks similar:

verify(mock, times(n)).method();


Replace n with your expected invocation count and maintain consistency across your tests.

Zero in on the behavior

Verify only the behaviors significant for your test. Over-specifying can create fragility and is considered an anti-pattern.

Weighing up different mocks on the scale of strictness

Let's run through the different ways Mockito allows us to verify non-invocations with various levels of strictness, and understand in what scenarios they best fit.

Challenging with never() or times(0)

These two add a specific challenge to your tests and are best for situations where you're sure a method shouldn't be called. Think of them as the "spam police" desperate to keep your inbox clean. 🚫✉️

Elevating to verifyNoInteractions()

This is rigorous, no-nonsense. It's the "curfew" that demands complete silence from your mock, no room is left for any activity here. 🚷

Coupling with @After using verifyNoMoreInteractions()

The "night guard" doing rounds after the day's work, ensuring all discrepancies are caught. Compared to verifyNoInteractions(), this accommodates some interactions and keeps a lookout for any unverified ones. Very useful for a comprehensive post-test check. 🌃

The deprecated vs the recommended

For any verifyZeroInteractions() seen out in the wild, let's move on to verifyNoInteractions() — the non-deprecated way. It's like switching from mullet hairdo to smart casual, updated style, same meaning. 💇‍♂️➡️👨‍💼