Introduction

Yes. Mockito can stub a method without caring about the specific argument value by using argument matchers such as anyInt(), anyString(), or any(). This is a normal pattern when the test cares about the returned behavior but not about the exact input value.

The key is to use the matcher that matches the method signature and to remember Mockito’s rule about consistency: once you use a matcher for one argument in a stubbing call, the other arguments in that same call must also be provided through matchers.

Basic Matcher-Based Stubbing

Suppose a service has a method that looks up a user by ID. If the test does not care which ID is supplied, stub it with a matcher.

1import static org.mockito.Mockito.*;
2
3class UserRepository {
4    String findNameById(int id) {
5        return null;
6    }
7}
8
9public class Demo {
10    public static void main(String[] args) {
11        UserRepository repo = mock(UserRepository.class);
12        when(repo.findNameById(anyInt())).thenReturn("Alice");
13
14        System.out.println(repo.findNameById(1));
15        System.out.println(repo.findNameById(999));
16    }
17}

Both calls return Alice because the stubbing ignores the concrete integer value.

Mockito provides type-specific helpers because they are clearer and safer than the raw any() form in many situations.

Choosing the Right Matcher

Use matchers that reflect the parameter type:

• 'anyInt() for int'
• 'anyLong() for long'
• 'anyString() for String'
• 'any(MyType.class) for custom reference types'
• 'nullable(MyType.class) when null should also match explicitly'

Example with an object parameter:

1import static org.mockito.Mockito.*;
2
3class Mailer {
4    boolean send(Message message) {
5        return false;
6    }
7}
8
9class Message {
10    String text;
11}
12
13public class MailDemo {
14    public static void main(String[] args) {
15        Mailer mailer = mock(Mailer.class);
16        when(mailer.send(any(Message.class))).thenReturn(true);
17
18        System.out.println(mailer.send(new Message()));
19    }
20}

This works regardless of which Message instance is passed.

Mixing Matchers and Exact Values

Mockito requires consistency within a single method call. If one argument uses a matcher, the others must also use matchers.

Incorrect:

when(service.combine("fixed", anyInt())).thenReturn("ok");

Correct:

1import static org.mockito.ArgumentMatchers.*;
2import static org.mockito.Mockito.*;
3
4when(service.combine(eq("fixed"), anyInt())).thenReturn("ok");

eq("fixed") is the matcher version of “this argument must be exactly this value.”

This rule exists because Mockito records matchers separately from literal values when building the stubbing specification.

When doReturn(...).when(...) Helps

For spies or methods with side effects, the doReturn(...).when(...) style is sometimes safer because it avoids invoking the real method during stubbing.

1import static org.mockito.Mockito.*;
2
3List<String> list = spy(new java.util.ArrayList<>());
4doReturn("x").when(list).get(anyInt());
5
6System.out.println(list.get(100));

With a spy, when(list.get(anyInt())) can call the real method while setting up the stub, which may throw. doReturn avoids that.

When Not to Ignore Arguments

Ignoring the argument is useful only when the argument truly does not matter to the behavior under test. If the code path should change depending on the argument, broad stubbing can make the test too weak.

For example, if a method should reject invalid IDs, anyInt() may hide a bug by making every input behave the same. In those cases, use eq, argThat, or separate stubs for different cases.

Common Pitfalls

A common mistake is using the raw any() matcher where a primitive-specific matcher is needed. For primitive parameters, prefer anyInt(), anyBoolean(), and similar helpers.

Another issue is mixing one matcher with one literal value in the same call. Once a matcher appears, all arguments in that stubbing call should be matchers.

Developers also sometimes use very broad matchers and then wonder why the test cannot distinguish important cases. If the argument matters semantically, do not stub too loosely.

Finally, remember that any() style matchers are for stubbing and verification in Mockito. They are not general Java expressions and do not carry real runtime values into the method body.

Summary

• Mockito can ignore argument values by using matchers such as anyInt() and anyString().
• Prefer the matcher that matches the parameter type.
• If one argument uses a matcher, the others in the same call must also use matchers.
• Use eq(...) when some arguments must match exact values.
• Avoid overly broad stubs when the argument itself is part of the behavior you want to test.