A Mockito test suite fails with InvalidUseOfMatchersException pointing at a test method whose code looks correct, and the failure disappears when that test runs alone. Explain how this happens and how you would locate the real culprit.

## The mechanism Mockito matchers do not travel as values. `any()`, `eq()`, `argThat()` and `captor.capture()` each push an `ArgumentMatcher` onto an `ArgumentMatcherStorage` held in a `ThreadLocal` (`MockingProgress`), then return a dummy default. The stack is *drained* when a mock invocation is intercepted and paired with its arguments. That means matcher registration and matcher consumption are separated in time. If nothing consumes them, they remain. The next intercepted invocation on that thread finds a non-empty stack whose size does not match its argument count - and throws `InvalidUseOfMatchersException` there. The stack trace points at code that is entirely correct; the guilty statement already returned. ## What leaves the stack dirty **Matchers outside stubbing/verification.** The classic is using a matcher as a plain value: ```java assertEquals(anyInt(), service.count()); // registers a matcher, never consumed ``` Also `anyString()` used to build test data, or a matcher passed to a real collaborator instead of a mock. **Uninterceptable methods.** Calling a `final`, `static`, or `private` method on a mock without `mockito-inline`/`mockStatic` means the real method runs and the invocation is never intercepted, so the matchers stay on the stack. Same for calling a method on a real object you forgot to mock, or on a field that was never initialised as a mock. **Argument evaluated but call abandoned.** An exception thrown between matcher evaluation and the mock invocation - for instance inside another argument expression, or by a helper that builds the mock target - leaves the stack loaded. **Misplaced argThat.** `argThat(...)` inside an assertion, inside a lambda that runs later, or captured into a variable for reuse registers at the wrong moment. Matchers are single-use and position-sensitive; storing one in a field and passing it to two verifications registers twice, once for each evaluation, but only when the expression is evaluated - not when the field is read. **Cross-thread work.** Because storage is thread-local, stubbing on the test thread while the production code invokes the mock on a worker thread will not consume the matchers on the test thread, and the worker's own invocation sees an empty stack. Symptoms look random. ## Diagnosing 1. **Turn on proper validation.** JUnit 5 `@ExtendWith(MockitoExtension.class)` calls `validateMockitoUsage()` after each test; the misuse is then reported on the test that actually caused it. With plain `MockitoAnnotations.openMocks(this)`, add `@AfterEach void tearDown() { Mockito.validateMockitoUsage(); }` yourself. This single change usually turns a mystery into a one-line fix. 2. **Read the exception body.** Mockito prints hints such as "This exception may occur if matchers are combined with raw values" and "matchers must be used with mocks, not real objects", plus the offending location once validation runs at the right time. 3. **Bisect the class.** Run methods in isolation, then in pairs, to find the predecessor that poisons the stack. Ordering matters, so a stable order (`@TestMethodOrder`) makes the bisect reproducible. 4. **Grep for matchers outside `when`/`verify`.** Static imports of `any*`/`eq`/`argThat` appearing inside `assert*`, data builders, or lambdas are the usual suspects. 5. **Check for final/static/private targets.** If the "mock" call is not interceptable, verification would also fail silently in other ways - confirm the mocking of that type is actually supported by the configured mock maker. ## Hardening against recurrence - Use `MockitoExtension` everywhere and keep strictness at `STRICT_STUBS`, so unused stubs and argument mismatches surface as failures in the right test. - Ban matchers outside `when`/`verify`/`doReturn(...).when(...)` in code review; matchers are not predicates for general use. - Do not share matcher expressions through fields or helper variables; call them inline at the point of use. - Keep one thread per test where possible, and stub before handing mocks to executors. ## Interview framing The grader is listening for the causal chain: thread-local stack, registration decoupled from consumption, therefore late and misattributed reporting, therefore validation hooks are the diagnostic. Naming `validateMockitoUsage()` / `MockitoExtension` as the fix is the differentiator between a candidate who has read the message and one who has debugged it.