Mockito Argument Matchers with verify | Java Fresher Interview

Argument matchers work exactly the same in verify as they do in when—you use them to assert that a mock was called with arguments matching a pattern instead of hardcoded exact values. This is critical when the exact argument isn't predictable at test time. For example, if your service logs an audit event with the current timestamp, you can't verify the exact millisecond, so you write verify auditLog dot record with anyLong and eq of USER_LOGIN. The timestamp can be anything, but the event type must be USER_LOGIN. The all-or-none rule still applies: if you use one matcher, all arguments in that verify call must be matchers. So if you want to verify a specific string alongside a wildcard, you have to wrap the string with eq. The big decision you make is how precise your verification should be. Using any for everything makes your test loose—it passes even if wrong data is sent. That hides bugs. On the other hand, using eq or argThat makes your test strict—it fails if incorrect values flow through, catching issues early. The balance is: use specific matchers or argThat when the argument matters for correctness. Use any when the value truly doesn't affect the behavior you're testing, like a correlation ID that just gets passed through. A common freshman mistake is writing verify with any for all arguments because it's easier, but that defeats the purpose—you're only checking the method was called, not that it was called correctly.