With MockK's JUnit 5 extension registered, how do you have a mock handed to a single test function as a parameter rather than declared as a class property, and what controls that mock's relaxation and name?

## The mechanism `MockKExtension` implements JUnit's parameter-resolution contract. For every parameter JUnit asks about, the extension looks for a MockK annotation on that parameter; if it finds one, it says it supports the parameter and then builds the value. That is the whole trick — there is no separate registration, no naming convention, nothing implicit. **A parameter with no MockK annotation is not touched**, which is why an unannotated parameter fails with JUnit's ordinary "no resolver" error rather than silently receiving a mock. Where it applies: any method whose parameters JUnit resolves — `@Test` functions, lifecycle methods, and the test class constructor. The constructor case is its own topic because ordering matters there. ## What gets created - `@RelaxedMockK param: T` → a relaxed mock: unstubbed calls return default values instead of throwing. - `@MockK param: T` → a strict mock by default; the annotation's `relaxed` and `relaxUnitFun` attributes are read and passed through, so `@MockK(relaxUnitFun = true)` gives you a mock that tolerates unstubbed `Unit`-returning calls but still fails on unstubbed value-returning ones. - `@AdditionalInterface(type = …)` on the same parameter adds a further interface to the created mock, for the case where production code casts the collaborator. Resolution happens **per invocation**. Declare two parameters of the same type and you get two independent mocks. Declare a `@MockK` property of type `Repo` *and* a `@MockK` parameter of type `Repo` and you have two different objects — a very common source of "I stubbed it but the call was never stubbed" confusion, because the class under test was wired with one of them and the stub went to the other. ## Naming, and why it is worth setting Every MockK mock has a name that shows up in error and verification messages ("no answer found for ...", the list of recorded calls). For a parameter mock the name is chosen in this order: the annotation's `name` attribute if you set one; otherwise the parameter's own source name — but only if parameter names survived compilation, which for Kotlin means the `-java-parameters` compiler flag; otherwise the mock is unnamed and messages fall back to a generic identifier. On a project that has not enabled that flag, setting `@MockK(name = "repo")` is cheap and makes failures readable. ## Why choose a parameter over a property **Locality.** A collaborator that exists for one test does not belong in class scope where every other test's reader has to decide whether it matters. A signature like `fun retries on timeout(@MockK clock: Clock)` says exactly which doubles the test involves. **No lateinit.** Property mocks are typically `lateinit var`, which is mutable class state that JUnit and the extension fill in; a parameter is a `val` with an obvious origin. **Cost.** Shared collaborators become repetitive noise if you thread them through five signatures, and shared stubbing in `@BeforeEach` cannot see a parameter that does not exist yet. So: shared setup → properties; one-off doubles → parameters. Mixing both in one class is normal and fine. ## Relationship to the rest of the extension Parameter resolution is independent of the property initialisation pass: a class with only parameter mocks still needs `@ExtendWith(MockKExtension::class)`, and it still gets the extension's end-of-test `unmockkAll()`/`clearAllMocks()`. Note also that a parameter mock is created *before* the test body runs, so `every { }` inside the test is the first thing that touches it — there is no pre-stubbing hook attached to the parameter itself. ## Failure modes to recognise - **Unannotated parameter** → resolution error from the test framework, not from MockK. Add the annotation. - **Extension not registered** → same error; the parameter resolver only exists when the extension is on the class (or auto-detected). - **Stub applied to the wrong instance** → you stubbed the property while the subject holds the parameter mock (or vice versa). Wire the subject inside the test from exactly the doubles you intend. - **Strict-mock surprises** → `@MockK` on a parameter is strict; unstubbed calls throw. That is usually what you want, but if the collaborator is a fire-and-forget sink, `@RelaxedMockK` is the honest choice.