Introduction

Mockito verification is about more than checking whether a method was called. In many tests, the important part is whether the method was called with the right arguments. Mockito supports several levels of strictness here, from exact value matching to flexible matchers to full argument capture for later assertions.

Exact Argument Verification

The simplest case is verifying exact values with verify.

1import static org.mockito.Mockito.mock;
2import static org.mockito.Mockito.verify;
3
4interface EmailSender {
5    void send(String to, String subject);
6}
7
8public class ExactVerifyExample {
9    public static void main(String[] args) {
10        EmailSender sender = mock(EmailSender.class);
11
12        sender.send("[email protected]", "Build complete");
13
14        verify(sender).send("[email protected]", "Build complete");
15    }
16}

This is a good fit when the expected values are simple and deterministic.

Use Matchers When Only Part of the Input Matters

Sometimes you care about one argument but not the others. Mockito matchers such as anyString(), eq(), and isNull() help express that.

1import static org.mockito.ArgumentMatchers.anyString;
2import static org.mockito.ArgumentMatchers.eq;
3import static org.mockito.Mockito.mock;
4import static org.mockito.Mockito.verify;
5
6interface AuditLog {
7    void record(String level, String message);
8}
9
10AuditLog log = mock(AuditLog.class);
11log.record("INFO", "User created");
12
13verify(log).record(eq("INFO"), anyString());

The important rule is consistency: once you use a matcher for one argument, use matchers for all arguments in that method call.

This is wrong:

verify(log).record("INFO", anyString());

This is correct:

verify(log).record(eq("INFO"), anyString());

Capture Arguments for Deeper Assertions

If the code under test builds a complex object and passes it into a dependency, exact verification can become awkward. ArgumentCaptor lets you inspect the real object after the call.

1import static org.junit.jupiter.api.Assertions.assertEquals;
2import static org.mockito.Mockito.mock;
3import static org.mockito.Mockito.verify;
4
5import org.mockito.ArgumentCaptor;
6
7class UserEvent {
8    private final String username;
9    private final String action;
10
11    UserEvent(String username, String action) {
12        this.username = username;
13        this.action = action;
14    }
15
16    public String getUsername() { return username; }
17    public String getAction() { return action; }
18}
19
20interface EventPublisher {
21    void publish(UserEvent event);
22}
23
24EventPublisher publisher = mock(EventPublisher.class);
25publisher.publish(new UserEvent("alice", "LOGIN"));
26
27ArgumentCaptor<UserEvent> captor = ArgumentCaptor.forClass(UserEvent.class);
28verify(publisher).publish(captor.capture());
29
30assertEquals("alice", captor.getValue().getUsername());
31assertEquals("LOGIN", captor.getValue().getAction());

Use a captor when the object has several fields and you want precise assertions on the constructed value.

Use argThat for Custom Matching

If the argument matters, but you only need to test a condition, argThat can be more direct than a captor.

1import static org.mockito.ArgumentMatchers.argThat;
2import static org.mockito.Mockito.mock;
3import static org.mockito.Mockito.verify;
4
5EventPublisher publisher = mock(EventPublisher.class);
6publisher.publish(new UserEvent("alice", "LOGIN"));
7
8verify(publisher).publish(argThat(event ->
9    event.getUsername().equals("alice") &&
10    event.getAction().startsWith("LOG")
11));

This is concise and keeps the verification close to the condition you actually care about.

Choose the Smallest Verification That Proves the Behavior

Good tests verify behavior without becoming brittle.

Use exact values when:

• the arguments are simple
• every value matters

Use matchers when:

• only some values matter
• the rest are noise for this test

Use captors when:

• the argument is complex
• you need multiple assertions on it

Use argThat when:

• a boolean predicate explains the requirement clearly

Picking the smallest sufficient tool helps keep tests readable and maintainable.

Common Pitfalls

The biggest Mockito mistake here is mixing raw values and matchers in the same call. Mockito rejects that because it cannot interpret the invocation consistently.

Another problem is over-verifying. If a test checks every field of every call, small refactors can break the test even though behavior is still correct. Verify what matters to the contract, not every incidental detail.

Mutable arguments are another trap. If the code passes an object to a mock and mutates it later, a captor sees the mutated object state. In that case, either verify earlier or make the argument immutable.

Finally, do not use captors everywhere. They are powerful, but exact verification or a matcher is often simpler and communicates intent better.

Summary

• 'verify(mock).method(...) is the basic way to check method arguments in Mockito.'
• Use matchers such as eq, any, and isNull when only part of the argument list matters.
• Use ArgumentCaptor when you need detailed assertions on a passed object.
• Use argThat for concise custom conditions.
• Avoid mixing raw values with matchers, and verify only the behavior that matters to the test.