In a MockK test you write `every { repo.find(any()) } returns A` and later, in the same test, `every { repo.find(1) } returns B`. Which stub wins, and does re-stubbing reset an existing answer chain or the mock's recorded calls?

## The dispatch rule in one sentence Each mock holds an ordered list of registered stubs — matcher plus answer. When a call arrives, MockK scans that list **in reverse registration order** and uses the first stub whose matchers accept the invocation. Last match wins. ## What that means in practice ### Recency beats specificity ```kotlin every { repo.find(any()) } returns A // registered first every { repo.find(1) } returns B // registered second repo.find(1) // B repo.find(2) // A ``` Swap the two lines and `find(1)` returns `A`, because the `any()` stub is now the most recent match and it accepts the argument `1`. Nothing in MockK ranks a literal matcher above a wildcard. This trips up people who expect the "most specific rule wins" behavior of routing tables or exception handlers. The practical convention that follows: in a shared `@BeforeEach` set up the broad defaults, and let individual tests add narrower overrides afterwards. That ordering works with the rule instead of against it. The inverse — a specific stub in setup and a broad `any()` stub inside one test — silently disables the setup for that test, which is one of the more annoying MockK debugging sessions. ### Re-stubbing the identical call ```kotlin every { clock.now() } returns t0 every { clock.now() } returns t1 // from here on, t1 ``` The second registration simply becomes the newest match. The first stub is still in the list but is never reached — it is shadowed, not deleted. Behaviorally that is indistinguishable from replacement, with one nuance: if you later clear only the newest registration you do not "fall back" to the old one, because clearing removes answers wholesale rather than popping the top of a stack. ### Chains reset An answer sequence is one object with an internal counter. Re-stubbing installs a *new* sequence object with a counter at zero: ```kotlin every { c.next() } returns 1 andThen 2 c.next() // 1 every { c.next() } returns 7 andThen 8 c.next() // 7, not 8 ``` This is exactly what you want for a test with two phases, and exactly what bites you if a helper function re-stubs a call you were mid-sequence on. ### Recorded calls survive Stubbing and recording are separate registers. Registering an answer never touches the invocation log, so a verification after a re-stub still counts calls made before it. If a test genuinely wants "phase two starts from zero", it must clear the recorded calls explicitly — typically `clearMocks(mock, answers = false, recordedCalls = true)`, since `clearMocks` exposes independent flags for answers, recorded calls, child mocks and verification marks. Note that clearing answers puts a non-relaxed mock back into the strict state where the next unstubbed call fails, which is often a *useful* way to prove nothing calls the collaborator after a certain point. ### The `every` block is not an interaction The lambda passed to `every` really does invoke the method, but MockK is in recording mode: the invocation is used to build the matcher and is not added to the call log. So stubbing a call five times does not make `verify(exactly = 5)` pass. Candidates occasionally believe the opposite and "explain" a failing count with it. ## Diagnosing precedence problems Symptoms of a precedence bug are distinctive: a stub you can see in the file appears to have no effect, or a value from a completely different test setup shows up. The checks, in order: 1. Look for a later `every` on the same function with a *wider* matcher — including ones hidden in helper functions, `@BeforeEach`, or a shared fixture builder. 2. Confirm the matchers really match what production passes (a stub on `find(1)` does nothing if the code calls `find(1L)` or passes a data object that is not equal). 3. Confirm nothing cleared the mock between setup and exercise. And the structural fix is usually to stop re-stubbing at all: one stub per call per test, defaults broad and early, overrides narrow and late. ## Summary - Reverse registration order; last matching stub wins; specificity does not matter. - Re-stubbing shadows the older answer and resets any sequence counter. - Recorded calls are independent of stubs and survive re-stubbing. - `every` blocks are recordings, not interactions. - `clearMocks` is the tool for actually removing answers, with per-register flags.