MockK's `mockk()` accepts a `name` parameter, as in `mockk<Repository>(name = "primaryRepo")`. What does that name actually affect, and when is it worth setting?

## What the parameter is The full creation entry point in MockK is roughly: ```kotlin mockk<T>( name: String? = null, relaxed: Boolean = false, vararg moreInterfaces: KClass<*>, relaxUnitFun: Boolean = false, block: T.() -> Unit = {}, ): T ``` `name` is the first of those creation options and the least behavioural: it changes **how the mock identifies itself in text**, nothing else. Matching, stubbing, verification, equality and hashing are unaffected. ## What it changes A MockK mock overrides its string representation. By default it renders as the simple type name plus a global creation counter — `Repository(#1)`, `Repository(#2)`, `Clock(#3)`. Supply `name = "primaryRepo"` and it renders as `primaryRepo`. That string surfaces in the places where you are already in pain: 1. **Strict-mock failures.** Calling an unstubbed method on a plain (non-relaxed) mock throws a `MockKException` whose message starts `no answer found for:` followed by the rendered call — `Repository(#2).find(7)` versus `replicaRepo.find(7)`. With two mocks of the same type, the ordinal tells you nothing; the name tells you everything. 2. **Verification failures.** When `verify` fails, MockK prints the expected call and a dump of the calls it actually recorded, keyed by mock. Named mocks turn that dump into something you can read at a glance. 3. **Incidental leakage.** If the code under test logs a collaborator, or an assertion message interpolates one, you see the mock's rendering. A named mock keeps that legible. ## Why the default is awkward The `#n` counter is **global to the process, not per test**. Mocks created by earlier tests in the same JVM advance the counter, so the same mock is not reliably `#1` across runs, and you cannot map an ordinal in a CI log back to a line of code by counting. This is the concrete reason experienced people name mocks in fixtures: the ordinal is not a stable identifier. ## When to bother Name them when identification is genuinely at risk: - **Two or more mocks of the same type** in one test — primary/replica, source/target, inbound/outbound clients. - **Mocks created in a loop or a factory** — `List(3) { mockk<Handler>(name = "handler-$it") }` turns an unreadable dump into an indexed one. - **Shared fixtures / base classes**, where the failing mock was created far from the failing assertion. - **Parameterised tests**, where the failure message is often the only clue about which case blew up. Skip it for a single-mock test: `Repository(#1)` is unambiguous there, and a name adds noise. ## Related creation surface worth knowing - The `block` parameter lets you stub at creation: `mockk<Repo> { every { find(1) } returns account }` — the receiver of the block is the new mock. This keeps naming and initial stubbing in one expression. - `mockkClass(Repository::class, name = "primaryRepo")` is the non-reified sibling of `mockk<T>()`: same options, but the type is passed as a `KClass` value. Use it when the type is only known at runtime — for example a generic test helper that receives a `KClass` — since `mockk<T>()` needs a reified type at the call site. - MockK's annotation-driven setup derives a name from the annotated **property name**, which is why annotation-based fixtures are often readable without ever touching `name` explicitly. ## The interview point The answer that scores is: *it is diagnostics only; it replaces the generated `Type(#n)` rendering in error and verification output; the counter is global so it is not a stable identifier; name mocks when a test holds several of a type or builds them in a loop.* Saying "it makes MockK track the mock" or "it's required for verify" is the failure mode — nothing in MockK's matching depends on the name.