In a large test suite using Mockito, argument assertions can live inside the verification as custom predicate matchers, or be pulled out and asserted separately on the recorded value. How do you decide which, and what does each choice cost in diagnosability and coupling?

## Two mechanisms, two jobs A custom matcher passed to argThat is evaluated by Mockito while matching invocations. It can therefore do things nothing else can: make when(...) return different answers for different arguments, disambiguate which of several recorded calls a verification refers to, and constrain a call inside verify(mock, times(2)) or an InOrder sequence. An extracted-value assertion runs afterwards on the actual argument and can use the full assertion library - recursive comparison, field exclusions, soft assertions, printed diffs. ## What each costs Predicate matchers cost diagnosability. The result is a boolean, so a failure can only say the call did not match; the wanted line is whatever toString() you wrote, and if you wrote none it is a synthetic lambda name. They also carry rules: pure, null-safe, non-throwing, possibly evaluated more than once. And they hide the assertion inside a call that also does other work, so a reader has to disentangle 'which call' from 'what was in it'. Extracted assertions cost expressiveness at match time. They cannot make a stub argument-dependent. When a method was called several times you must decide which occurrence you meant, which is exactly the discrimination a matcher does for free. And they run only after the verification has already passed, so a wrong-call-shape failure and a wrong-content failure surface in two different places. ## A decision rule that survives a large suite 1. Does the condition need to affect matching - stubbing behaviour, picking one of several invocations, ordering? If yes, it must be a matcher. 2. Otherwise, is the condition trivially obvious on failure - a single flag, one enum, an id? An inline predicate is fine, and cheaper to read than a two-step extract-and-assert. 3. Otherwise - several fields, numeric tolerance, collection contents - assert on the value outside the verification, where a failure explains itself. 4. Anything appearing in three or more tests becomes a named ArgumentMatcher with a domain name and a toString(), or a shared assertion helper. Duplicated inline predicates are how suites drift. ## Coupling, the other axis Both mechanisms couple the test to the collaborator's call shape; the question is how much of the argument's internals the test pins. Asserting every field of a large DTO makes any construction change break dozens of tests, and teams respond by deleting assertions rather than fixing them. Asserting nothing lets real regressions through. The stable middle is to assert the fields that carry the behaviour under test and be explicit about ignoring the rest - excluded fields in a recursive comparison, or a matcher whose description names precisely what it checks. The description doubles as documentation of what this test claims. ## Failure-mode economics At suite scale, judge these choices by triage cost. A CI failure that reads 'Wanted: repo.save(a PENDING order with total > 100), Actual: save(Order[status=PENDING, total=99.99])' is fixed from the log. A failure that reads 'Wanted: save(Test$$Lambda$14@6d06d69c)' requires a local reproduction and a debugger. Multiply by the number of failures a large suite produces during a refactor and the policy pays for itself. That is also why assertions must never be embedded inside matchers - they promise a good message and deliver a confusing one, because Mockito may evaluate the matcher repeatedly and while composing its own report. ## Where strictness fits Whichever route you take, run strict stubs. A predicate stub whose arguments never matched is invisible otherwise: the test passes because the code took a path you did not intend, and no assertion fires. Strict stubbing turns that silent mismatch into a failure and is the backstop that makes argument-dependent stubbing safe to use at all.