A collaborator you are mocking takes a lambda parameter — something like retry(times: Int, block: () -> String). Using MockK, how do you get hold of that lambda and actually run it, and what is the difference between doing it inside an answers block and capturing it into a slot for later?

## Why lambdas need their own story A function argument in Kotlin is an ordinary value, so a lambda parameter can be matched with `any()` and captured with `capture(slot)` like anything else. What makes it interesting is that a test usually does not want to *inspect* the lambda — you cannot meaningfully assert on a function object — it wants to *run* it, because the interesting logic lives inside the block the production code passed in. If the mock swallows the block, that code is never executed and the test silently covers nothing. ## Running it during the call: captureLambda + answers `captureLambda()` is a MockK matcher written in the argument position of the function parameter. It matches the function argument and stores it where the answer scope can find it. Inside the `answers { }` block, `lambda<T>()` gives you that captured function typed as `T`, and MockK provides `invoke` support so you can call it directly: ```kotlin every { retrier.retry(any(), captureLambda()) } answers { lambda<() -> String>().invoke() } ``` The type argument to `lambda<...>()` must match the real parameter type — MockK cannot infer it from the answer block, and getting it wrong surfaces as a cast failure at run time rather than a compile error. Note what this stub *is*: a mock that behaves like the real wrapper. The block runs synchronously inside the call, whatever it returns becomes the value the answer produces, and an exception thrown by the block propagates out of the mocked call exactly as it would in production. That is precisely what you want when mocking transaction wrappers, retry helpers, `use`-style resource scopes or `measureTime`-shaped utilities: the code under test only makes progress if the block actually runs. ## Running it later: capture into a slot When the collaborator's contract is "take this callback and call it eventually", the test wants control over *when*. Because a lambda is a value, a plain slot works: ```kotlin val cb = slot<(Result) -> Unit>() every { client.fetch(any(), capture(cb)) } just Runs service.load() cb.captured(Result.Ok("data")) ``` The stub returns immediately having done nothing, and the test then fires the callback to drive the next phase — success first, then re-run and fire a failure. This gives deterministic tests for asynchronous-looking APIs without any real threading. The same slot rules apply as for values: the slot holds the *last* captured lambda, and `isCaptured` tells you whether production registered one at all — a useful assertion in its own right ("the service registered a listener"). ## Suspend lambdas If the parameter is a suspending function, the ordinary lambda helpers cannot invoke it. MockK provides the coroutine-aware pair: `captureCoroutine()` as the matcher and `coroutine<T>().coInvoke(...)` inside a `coAnswers { }` block to call it from a suspending context. The shape is otherwise identical. ## Choosing between the two Ask what the collaborator's contract is: - *It runs my block and returns its result* (transaction, retry, lock, timing wrapper) → `captureLambda()` + `answers`, invoking immediately. Anything else means the block is never exercised and coverage lies. - *It stores my block and calls it later* (listener registration, async callback, event subscription) → capture into a slot and invoke from the test when you want that phase to happen. ## Failure modes to expect - **The block never runs.** A stub written as `every { tx.inTransaction(any()) } returns Unit` matches happily and drops the lambda; every assertion about work done inside the transaction fails, or worse, passes vacuously. Reach for `captureLambda` the moment the parameter is a function you rely on. - **Wrong type parameter.** `lambda<() -> Unit>()` where the real type is `(Int) -> Unit` fails at run time, not compile time. - **Invoking a slot that was never captured.** If no call matched, `isCaptured` is false and calling `captured` is meaningless — assert the registration happened first. - **Re-registration.** If production registers several callbacks and you hold one slot, you invoke only the last; capture into a `MutableList` when there can be more than one.