A Mockito verification written as verify(repo).save(any()) still passes after a bug is introduced that saves the wrong object. Using Mockito's built-in matchers, how would you tighten it, and what do eq() and same() each buy you?

## Why any() cannot fail verify(repo).save(any()) asserts one thing: save was invoked once with some argument. Every property of that argument is unconstrained, so a regression that builds the wrong entity, drops a field, or passes a stale copy leaves the test green. Suites drift into this state because any() is the quickest way to make a red test pass, and nothing later flags the lost coverage. ## The built-in ways to tighten - eq(value) - the argument must equal value per equals(). This is the workhorse, but its strength is entirely inherited from the class. If the class does not override equals(), Object.equals is identity, so eq() quietly becomes same() and will fail for an equal-but-distinct instance. - same(value) - reference identity (==). Use it when the assertion really is 'this exact object was passed through', for example a handler that must forward the received event rather than reconstruct it, or a connection that must not be wrapped. - refEq(value, excludedFields) - reflective field-by-field comparison, with fields you can exclude by name (generated ids, timestamps). It rescues classes without equals(), at the cost of being brittle to field additions and of comparing private state. - isA(Foo.class) / any(Foo.class) - a weak but non-zero constraint: the argument is a non-null Foo. Worth using over any() for overloaded or polymorphic parameters, particularly exception types. - The String helpers - startsWith, endsWith, contains, matches(regex) - constrain part of a value when the whole of it is unstable, for instance a message containing a generated id. ## The mutation trap Mockito records the invocation by holding references to the arguments. Verification runs later, so the comparison sees the object's state at verification time, not at call time. If the code under test does repo.save(order) and then mutates order, eq(expectedOrder) is comparing against the mutated object. This produces both false passes and confusing false failures, and it is the reason people mistrust argument assertions on mutable entities. If your production code mutates after the call, assert on an immutable projection - an id, a copied field - rather than on the whole object. ## Deciding how tight A workable rule: for each argument, ask whether a wrong value there would be a bug the test claims to prevent. If yes, constrain it exactly. If no - a clock, a correlation id, a logger - leave it loose and say so with any(). The failure mode of over-tightening is real too: verifying every field of a large DTO couples the test to construction details, so any unrelated change to the object breaks dozens of tests and teams start deleting assertions wholesale. ## Backstops beyond matchers Strict stubs (MockitoSession or the JUnit 5 extension with Strictness.STRICT_STUBS) catch stubs whose arguments never matched, which is the complementary failure - a stub written with a wrong value silently never applying. Combining strict stubs with deliberate matcher choice is what keeps a mock suite honest. For assertions too complex to express as a built-in matcher, extracting the value and asserting on it separately is the usual alternative, but the decision starts here: use the loosest matcher that still fails on the bug you care about.