MockK lets you write either spyk(MyService(...)) or spyk<MyService>(). How does the underlying instance come into existence in each case, and when does the second form blow up at runtime?

## Two ways to get a spy MockK's `spyk` has two shapes: ```kotlin val a = spyk(PriceCalculator(taxTable)) // spy a real, constructed instance val b = spyk<PriceCalculator>() // spy a class, MockK makes the instance ``` Both give you the same *behavioural* contract — unstubbed members execute the class's real code, every call is recorded for `verify`, and you can override selected members with `every`. What differs is where the object's fields come from. ## Form one: spyk(instance) You build the object with a normal constructor call. All the usual Kotlin initialisation has happened: constructor parameters assigned, property initialisers evaluated, `init` blocks executed, `lateinit` properties possibly set. MockK then copies those field values into its own instrumented instance. The spy starts life fully initialised, and real methods behave as they do in production. Cost: you must be able to construct the class in a test. If the constructor demands a database handle, opens a socket, or reads configuration, that cost lands in your test. ## Form two: spyk<T>() Here MockK creates the instance itself, and — this is the part candidates miss — **it does not call a constructor**. Object creation for mocks bypasses constructors entirely, which is what lets MockK mock classes whose constructors are unpleasant. The resulting object is structurally a `T`, but every field sits at its JVM default: - reference fields: `null` - numeric fields: `0` / `0.0` - boolean fields: `false` Nothing in your class ever assigned them, because nothing in your class ran. ### What that means for real method calls A spy runs real code for anything unstubbed. So the first unstubbed method that reads a field explodes in one of two ways: - a plain `NullPointerException` deep inside your own code, because a non-null-typed field is actually `null`; - `UninitializedPropertyAccessException: lateinit property repository has not been initialized`, because `lateinit` checks the backing field for null on read and MockK left it null. The stack trace points at *your* class, not at MockK, which is why this is confusing the first time. ### When form two is the right choice - The class is effectively stateless — pure functions over parameters. Then the empty fields never matter. - The constructor is expensive or does I/O, and you intend to stub every method the test will actually reach, so no real code touches a field. - You are testing one algorithmic method that only uses its arguments. In every other case, prefer `spyk(RealThing(...))`. If constructing the real thing is painful, that pain is information about the class's design, and hiding it behind a constructor-free spy usually trades a clear failure for a mysterious one. ## Choosing deliberately A good rule: pick `spyk(instance)` by default, and reach for `spyk<T>()` only when you can articulate why no real code will read state. If you find yourself stubbing more and more methods on a `spyk<T>()` to keep it from throwing, you have effectively built a mock the hard way — create a mock instead. ## Related knobs at creation time `spyk` also accepts a `name` (which shows up in MockK's error and verification messages, making failures readable when several spies are in play) and `recordPrivateCalls` (see private-call recording). Both apply to either form. ## Diagnosing it in the wild Symptom: a spy-based test throws an NPE or `UninitializedPropertyAccessException` from inside production code that plainly cannot be null in production. Check the spy's construction form. If it is `spyk<T>()`, either switch to spying a constructed instance, or stub the method that is reading the field so the real code never runs.