Coroutines, Annotations and JUnit 5

## Annotations do nothing by themselves `@MockK`, `@RelaxedMockK`, `@SpyK` and `@InjectMockKs` are plain Kotlin annotations. Nothing in the JVM acts on them; no compiler plugin rewrites your class. They are metadata waiting for someone to read it. `MockKAnnotations.init(...)` is that reader: it takes one or more objects, reflects over their properties, finds the annotated ones, constructs the appropriate double for each and assigns it to the property. So the mental model is a two-step: *declare* with an annotation, *materialise* with `init`. Miss the second step and you have a test class full of declarations and no objects. ## What init creates for each annotation - `@MockK lateinit var repo: Repo` → `mockk<Repo>()` assigned to `repo`. Optional parameters on the annotation (`relaxed`, `relaxUnitFun`, and a name) are passed through to the creation. - `@RelaxedMockK lateinit var repo: Repo` → the same as `@MockK(relaxed = true)`. - `@SpyK var clock = FixedClock()` → a spy wrapping the value the property already holds; that is why a `@SpyK` property must be initialised by you and is normally a plain `var`, not `lateinit`. - `@InjectMockKs` → handled after the mocks exist, so the subject can be wired from them. That last point is an ordering guarantee worth remembering: within a single `init` call, the doubles are created first and injection into the subject happens afterwards. Otherwise there would be nothing to inject. ## The failure mode when you forget Because `@MockK` properties are conventionally `lateinit var`, forgetting `init` does not produce a null — Kotlin's `lateinit` throws on read: ``` kotlin.UninitializedPropertyAccessException: lateinit property repo has not been initialized ``` The stack trace points at your test code, not at MockK, so the cause is easy to misdiagnose. Any time you see that exception in a MockK test, the first two hypotheses are: (a) `init` was never called, or (b) it was called *after* something already used the property. ## Where to call it The conventional place is a setup method that runs before each test: ```kotlin @BeforeEach fun setUp() = MockKAnnotations.init(this) ``` JUnit's default lifecycle creates a new test-class instance per test method, so `init` runs per test and each test gets fresh, unstubbed doubles — no cross-test bleed from stubs or recorded calls. If a class-level lifecycle is used instead, the instance and its mocks are shared and you must clear them between tests yourself. `init` accepts several objects (`MockKAnnotations.init(this, other)`), which is occasionally useful when annotated properties live on a shared base or helper object. ## Class-wide flags `init` takes named parameters that apply to every annotated mock it creates in that call — notably `relaxUnitFun = true` and `relaxed = true`. `MockKAnnotations.init(this, relaxUnitFun = true)` is the compact way to say "none of these mocks should force me to stub `Unit` members", instead of repeating a parameter on each annotation. Per-annotation settings remain available when only one mock needs different treatment. ## The alternative to calling it yourself On JUnit 5, MockK ships an extension that performs the initialisation for you when the test class is annotated with it; then the explicit `init` call is redundant and should be removed rather than duplicated. That integration is a topic of its own; the thing to hold onto here is simply that *something* must run the initialisation, and if no extension is doing it, your setup method must. ## Interview-shaped summary Say it as a chain: annotations are inert → `init(this)` reflects and assigns → mocks first, subject injection second → forgetting it surfaces as `UninitializedPropertyAccessException` on first use → JUnit's per-method instance means it re-runs and mocks are fresh → `relaxUnitFun`/`relaxed` on the `init` call configure the whole class at once.