You need to assert that a collaborator was called from a background thread or from a coroutine launched on a real dispatcher. How do MockK's verify(timeout = ...) and coVerify(timeout = ...) make that reliable, and what situation makes the verification burn the whole timeout and fail even though the production code is correct?

## Why polling works at all A MockK mock keeps a record of the calls made on it. That record belongs to the mock instance, not to the thread that made the call, so a callback invoked on a worker thread lands in the same place a call from the test thread would. Timeout verification exploits exactly this: the test thread repeatedly re-evaluates the verification block against that shared record until it is satisfied or the deadline expires. No cooperation from the production code is required — you do not need a hook, a callback, or an idle signal, only a mock the code eventually touches. ## The two entry points ``` // callback delivered on an executor thread verify(timeout = 2000) { listener.onFinished(file) } // suspend collaborator called from a coroutine on a real dispatcher coVerify(timeout = 2000) { repository.save(any()) } ``` `coVerify` exists because MockK records suspend calls through a separate path; the `timeout` parameter means the same thing on both, and both block the caller while they wait. ## The starvation trap The crucial mechanical fact is that MockK's wait is a **blocking wait on the calling thread**. It does not yield to a scheduler, it does not pump a queue, it does not advance anything. So the wait only works if the outstanding work is being carried by *some other* execution resource. The cases where that is not true look like this: * The production code submits work to an executor that the test wired up to run tasks on the caller's thread (a direct or same-thread executor). Blocking the caller means the task queue is never drained. * The coroutine is launched on a dispatcher that is confined to the test thread, or on a scheduler whose tasks only run when the test itself drives it. Blocking the test thread stops any of it from progressing. * The work is queued behind the very call the test is still inside — a single worker already occupied by something the test must return from first. In all of these, the symptom is identical and confusing: the assertion always takes exactly the timeout and then reports that the call never happened, while the production code is perfectly fine. The tell is that the test duration equals the timeout precisely — a real async race would sometimes pass. When the execution is confined to the test thread, the fix is not a longer timeout; it is to let the work run (drive the executor/scheduler explicitly, or run the code on a genuinely separate thread) and then verify without waiting at all. ## Silent worker failures The second trap is diagnostic rather than mechanical. When code running on a background thread throws, nothing propagates into the test thread; the JVM's default handling logs it or drops it. Your timeout verify then fails with MockK's normal "no matching calls" message and lists what *was* recorded. That message never says "the worker died". So when a timeout verification fails, the first hypothesis should be "the work crashed before reaching this call", not "the timeout was too short". Practical mitigations: give the executor an uncaught-exception handler that fails the test, or stub the collaborator with `answers { ... }` that records enough context to tell you how far execution got. ## Ordering and multiple waits Only the calls named in the block are known to have happened when `verify` returns; other in-flight work is still in flight. Two consequences follow. First, chain waits deliberately — wait for the call that means "the pipeline finished", then assert everything else with plain verifies. Second, remember that `verifyOrder` and `verifySequence` take no timeout; if you need ordered verification with waiting, call `verify` itself and pass both `ordering` and `timeout`. ## How to choose the deadline Pick a value that comfortably exceeds the worst thread-scheduling latency on your slowest CI agent — seconds, not tens of milliseconds. Because the loop returns as soon as the call is recorded, a generous deadline costs nothing on green runs and only shows up on genuine failures. Tightening timeouts to speed up a suite is optimising the one case that is already fast, and buying flakiness with the saving.