Verify Invocation Count Modes
Fast recall
Quick revision
Core answer
Interview-ready guide
Interview answer
VerificationMode is how you specify how many times a method should have been called in Mockito.
The most common is times n, which asserts exactly n calls.
For example, verify mock comma times 3 dot method checks that method was called exactly three times. If it was called more or fewer, the test fails. Then there's atLeast n, which asserts at least n calls — useful for retry logic where you want to ensure it tried at least three times before giving up.
And atMost n, which asserts no more than n calls — useful for capping retry attempts to avoid infinite loops. There's also never, which is equivalent to times 0 — it asserts the method was never called at all. One thing freshers don't always realize is that the default verify mock dot method without a count argument is actually times 1 — it checks for exactly one call.
If the method was called twice, the test fails.
A common mistake is over-specifying call counts in every test. If you write times 1 explicitly everywhere, your tests become brittle — if you refactor and split one call into two for clarity, all those tests break even though the behavior is still correct. I'd only verify counts when the count itself is semantically important, like batch size or retry limits.
If it's just an implementation detail, don't lock it down.
Verify Invocation Count Modes
Direct Answer
times(n) asserts exactly n calls; atLeast(n) asserts at least n calls; atMost(n) asserts no more than n calls — all are passed as the second argument to verify().
Code Example
service.retrySend(message);
verify(sender, times(3)).send(message); // exactly 3 calls
verify(sender, atLeast(1)).send(message); // 1 or more
verify(sender, atMost(5)).send(message); // up to 5
verify(logger, never()).error(any()); // zero calls
Common Mistakes & Pitfalls
- Not knowing the default: Freshers use verify(mock).method() without realizing it implicitly checks times(1). If the method was called twice, the test fails. They're confused why the test breaks even though the method was called.
- Over-specifying counts: Adding explicit times(1) or times(n) to every verify makes tests brittle. If you refactor and the call count changes (like splitting one call into two for clarity), tests break even though behavior is correct. Only verify counts when the count is semantically important.
- Using times(0) instead of never: They're equivalent, but never() is clearer intent.
- Wrong mode for the need: Using times(n) when you mean atMost(n) — for example, verifying retry logic with times(3) fails if it succeeded on the second attempt, but atMost(3) would pass. Choose the mode that matches your acceptance criteria.
Check your understanding
Answer these without looking back at the article.
- How do you verify that a method was called at least twice but no more than four times?
- What is the difference between never() and verifyNoInteractions()?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.