A MockK test declares `@MockK lateinit var repo: Repo` and builds the subject in a property initialiser: `val service = OrderService(repo)`. Why does it blow up, and how do you order the setup correctly?

## The timeline Three things happen in a fixed order, and every version of this bug comes from assuming a different order: 1. **The test-class instance is constructed.** All property initialisers run here, top to bottom, exactly as in any Kotlin class. 2. **The setup method runs** (`@BeforeEach` or its equivalent). This is where `MockKAnnotations.init(this)` normally lives, and it is where the annotated `lateinit` properties finally receive their mocks. 3. **The test method runs.** So any expression written as a property initialiser executes in step 1, when every `@MockK lateinit var` is still unassigned. Kotlin's `lateinit` mechanism does not give you a null in that window — it throws `UninitializedPropertyAccessException` with the property's name, which is fortunately a very informative message once you know where to look. ## Why it is so easy to write `val service = OrderService(repo)` reads like a declaration of intent — "the subject is the service built from these collaborators" — and it compiles perfectly. Nothing in the type system marks `repo` as "not yet assigned"; that is exactly the tradeoff `lateinit` makes. The failure only appears at runtime, on every test in the class, usually as a stack trace pointing at the test class's constructor rather than at any test method. Candidates who have not hit it before often blame MockK's initialisation instead of their own evaluation order. ## The three fixes **Assign after init.** The most explicit form: ```kotlin @MockK lateinit var repo: Repo lateinit var service: OrderService @BeforeEach fun setUp() { MockKAnnotations.init(this) service = OrderService(repo) } ``` The wiring stays hand-written and compile-checked, and the ordering is visible in two adjacent lines. Note the order *within* the method matters too: constructing the subject before `init` reproduces the same exception. **Delegate to MockK.** `@InjectMockKs lateinit var service: OrderService` removes the ordering question entirely, because injection happens inside `init` after the doubles exist. The cost is that the wiring becomes reflective and no longer compile-checked. **Make it lazy.** `val service by lazy { OrderService(repo) }` defers evaluation to first use, which happens inside the test method, after setup. It works, but it hides an ordering constraint behind a delegate; use it when you have a reason, not by default. ## What *is* safe in an initialiser Property initialisers that do not touch annotated mocks are fine, and one of them is idiomatic: `@SpyK var clock = FixedClock(EPOCH)`. That expression only uses a literal, so construction-time evaluation is harmless — MockK later replaces the property's value with a spy around it. The rule generalises cleanly: an initialiser may reference only what exists at construction time. ## Per-test freshness Because JUnit's default lifecycle creates a **new** test-class instance for each test method, the whole sequence repeats per test: fresh instance, fresh mocks from `init`, fresh subject. That is what keeps stubs and recorded calls from leaking between tests, and it is another reason to build the subject in setup rather than trying to cache it — a cached subject would hold mocks from a previous test's initialisation. ## Related orderings that bite - **Stubbing before `init`.** Any `every { repo… }` written above the `init` call in the same setup method fails for the same reason. - **Two initialisation mechanisms.** If a JUnit 5 extension already initialises the annotations and you also call `MockKAnnotations.init(this)`, the mocks are created twice and the second set replaces the first — stubs recorded against the first set then appear to vanish. Pick one mechanism. - **Subject built from a spy.** Spies are also only wrapped during `init`, so a subject constructed in a property initialiser would capture the raw object rather than the spy, and verifications against the spy would see nothing. ## The sentence that answers the question "Property initialisers run at instance construction, before `@BeforeEach` and therefore before `MockKAnnotations.init(this)`, so the `lateinit` mock is still unassigned and Kotlin throws `UninitializedPropertyAccessException`. Build the subject after `init` — in the setup method, via `@InjectMockKs`, or lazily."