What does MockK's `callOriginal()` do inside an answer block, on which kinds of mocks does it work, and why would you use it instead of simply leaving the function unstubbed?

## What it is `callOriginal()` is available on MockK's answer scope, so it can be used anywhere a block-form answer can: `answers { }`, `andThenAnswer { }`, and the coroutine-aware block form. It executes the **original implementation** for the invocation MockK intercepted and returns its value. Think of it as "proceed" in interception terms. ## Where an "original" exists MockK intercepts calls in different ways, and only some of them leave a real implementation to proceed to: - **Spies** (`spyk(realObject)` / `spyk<T>()`) — the whole point of a spy is that a real implementation sits underneath, so `callOriginal()` is available for any member. - **Objects, statics and constructors patched in place** — when MockK has replaced the behavior of a real object, a file facade's functions, or constructed instances, the original bodies still exist and can be invoked. - **Plain `mockk<T>()`** — there is nothing underneath. For an interface there is no implementation at all; for a class, MockK created an instance whose members are entirely intercepted. `callOriginal()` here has no original to dispatch to and fails with a MockK exception. This is the single most common surprise. Abstract members are the same story: there is no body to call, so asking for the original is meaningless. ## Why not simply not stub it? On a spy, an unstubbed member already runs the real code, so `callOriginal()` looks redundant. It stops being redundant as soon as the answer is *conditional* or *wrapped*: **Conditional overriding** — real behavior in general, forced behavior for a specific input: ```kotlin every { pricing.quote(any()) } answers { val req = firstArg<Request>() if (req.currency == "XXX") Quote.unavailable() else callOriginal() } ``` Not stubbing gives you the real path for *all* inputs; a plain `returns` gives you the fake path for all inputs. Only an answer block with `callOriginal()` splits the input space. **Wrapping** — run the real code but observe or adjust around it: ```kotlin every { parser.parse(any()) } answers { val result = callOriginal() result.copy(source = "test") } ``` **Selective restoration on patched objects/statics** — once you have patched an object, you may want most of it mocked but one member behaving normally. `every { Config.load() } answers { callOriginal() }` puts one member back without unpatching everything. **Failure injection with real behavior for the rest of the sequence** — combined with a chain, e.g. throw on the first call and proceed for the rest. ## Costs and cautions - **You are running production code inside a test double.** Everything the original does — I/O, clock reads, database access, other collaborators — happens for real. If the original was the reason you introduced a double at all, calling it back defeats the purpose. - **Partial mocking is a design signal.** Needing real behavior for some members and fake behavior for others on the same object often means the class has two responsibilities that want splitting. Reach for `callOriginal()` when you are testing code you cannot easily change (legacy, third-party base classes); treat it as a smell in code you own. - **Recording still happens.** The call is intercepted and recorded before the original runs, so verifications see it — that is precisely what a spy is for. - **Recursion and self-calls.** If the original implementation calls other members of the same object, those calls are also intercepted, which can produce surprising interactions with your other stubs on the same double. Keep the set of stubs on a partially-mocked object small and explicit. ## Typical exam answer "`callOriginal()` proceeds to the real implementation from inside an answer block. It works where a real implementation exists — spies, and objects, statics or constructors MockK has patched — and fails on a plain mock because there is nothing underneath. I use it for conditional stubs: real behavior in general, forced behavior for one input, or to wrap the real result. I avoid it as a routine tool, because running production code inside a double is usually a sign the class wants splitting."