A single MockK mock stands in for an interface that has both suspend and ordinary functions. How do you stub and verify each kind, and can one verification block cover calls of both kinds?

## The mock does not care There is no such thing as a "coroutine mock" in MockK. `mockk<OrderClient>()` produces one object that can answer every member of the type — `suspend fun fetch(id: String): Order`, `fun stream(): Flow<Order>` and `fun close()` alike. Stubs for all three live in the same mock's record. What changes between them is only which DSL entry point you use to *record* the stub or the verification, and that choice is dictated by Kotlin's rules about suspend calls, not by MockK. ## The rule in one sentence `every`, `verify`, `verifyOrder`, `verifySequence`, `justRun` take ordinary lambdas; `coEvery`, `coVerify`, `coVerifyOrder`, `coVerifySequence`, `coJustRun` take suspending lambdas. A suspend call may only appear inside a suspending lambda — otherwise the compiler says *Suspension functions can be called only within coroutine body*. Therefore: - suspend member → you **must** use the `co` variant; - ordinary member → either works, because a suspending lambda is perfectly happy to contain non-suspending calls. That one-way flexibility is the key mechanic. It is not a loophole; it is why a mixed verification block is possible at all. ## Stubbing a mixed collaborator Write each stub with the matching entry point: ``` every { client.stream() } returns flowOf(order) justRun { client.close() } coEvery { client.fetch("42") } returns order ``` Using `coEvery` for the blocking members too would compile and behave identically. Most teams still prefer the plain form for blocking members, because the prefix then documents which members suspend — useful information when reading a large setup block. ## Verifying a mixed interaction For a single unordered assertion, verify each kind with its own call, or put both inside one `coVerify`. When the *order* across kinds matters — "fetch first, then close" — you need one block that can contain both calls, and only the `co` form can: ``` coVerifySequence { client.fetch("42") client.stream() client.close() } ``` The reverse is impossible: no plain `verifySequence` can mention `fetch`, because that call cannot be written in a non-suspending lambda. ## The Flow trap The single most common mistake on mixed interfaces is assuming that anything coroutine-flavoured is suspend. A function declared `fun stream(): Flow<Order>` is an ordinary function that returns a cold stream object; nothing suspends until something collects it. So it is stubbed with `every { client.stream() } returns flowOf(order)`. Candidates who reach for `coEvery` here are not wrong at runtime (it compiles and works, since the block accepts ordinary calls), but they reveal that they think the prefix tracks "coroutines" rather than "this call site suspends". The same applies in reverse: `suspend fun fetch()` needs `coEvery` even though nothing about it mentions `Flow` or dispatchers. ## Calling the mock in the test Stubbing a suspend member is not enough to *invoke* it — the invocation still has to happen inside a coroutine, so the test body needs a coroutine builder or a suspending test function. That is a property of Kotlin, not of MockK: the mock itself imposes no requirement about scope, dispatcher or scheduler. ## Things that trip people up - **"I need two mocks, one for suspend and one for blocking."** No — one mock, two DSL entry points. - **"`verify` should work, MockK is just being awkward."** It is a compile error from Kotlin, not a MockK restriction, and it disappears the moment you use `coVerify`. - **"`coEvery` everywhere is fine."** It works, but it stops the prefix from carrying information; a reader can no longer tell from the setup which members suspend. - **Mixing kinds in an *ordered* verification and reaching for `verifyOrder`.** Only the `co` form can express the mixed sequence. ## The takeaway The `co` prefix is a statement about the lambda you are writing, not about the mock, not about the collaborator, and not about coroutines in general. Read every stub as: *does this call site suspend?* If yes, prefix it. If no, either form works and the plain one documents intent better.