In an async-heavy test suite, when would you rely on MockK's verify(timeout = ...) versus building deterministic synchronization — for example counting down a latch inside an answers block, or injecting the executor or dispatcher so the work runs on the test thread? How do you keep such a suite from becoming flaky or slow?

## Framing the decision There are three ways a test can cope with work that happens off the test thread: make it not happen off the test thread (inject the execution seam), wait for an explicit signal (a latch or barrier driven from a stub), or poll for the outcome (MockK's `verify(timeout = ...)`). They are ordered from most deterministic to least, and from most intrusive on production design to least. The engineering call is where on that spectrum a given test should sit, and the answer usually follows from who owns the code. ## Option 1 — inject the seam (default when you own the code) If a component accepts its `Executor`, `CoroutineDispatcher` or scope as a constructor dependency, the test can hand it one that executes work on the calling thread. Concurrency disappears from the test entirely: the call under test returns only after the collaborator was touched, every assertion is a plain `verify`, exact counts and ordering are meaningful, and absence assertions are real. Run time is zero-cost and there is nothing to flake. The price is a design constraint on production code — the class must not create its own threads internally. In practice that constraint is worth paying for on its own merits, because it is also what makes timeouts, shutdown and back-pressure configurable in production. When I review a class that needs timeout verification to be testable, my first question is whether it should be taking its executor as a parameter. ## Option 2 — an explicit barrier built from a stub When you cannot control where the work runs, you can still control what happens *when it lands*, because the collaborator is a mock: ``` val done = CountDownLatch(1) every { listener.onFinished(any()) } answers { done.countDown() } uploader.upload(file) assertTrue(done.await(5, TimeUnit.SECONDS), "upload never finished") verify(exactly = 1) { listener.onFinished(file) } verify(exactly = 0) { auditLog.record(any()) } ``` This is strictly more capable than polling: the latch establishes a defensible "the work is finished" moment, after which exact counts, ordering assertions and negative assertions are all legitimate. The failure message is also yours to write, which is worth more than it sounds when a test fails once a fortnight on CI. The cost is a few lines of ceremony and the discipline to count the latch down in the right stub. ## Option 3 — timeout verification `verify(timeout = ...)` is the same barrier with no ceremony and no production seam. For the common case — "this collaborator eventually gets called" — it is the right tool and I would not push back on it in review. Its limitations define where it stops: it cannot assert absence (an already-true verification returns immediately), `verifyOrder`/`verifySequence` take no timeout, and it tells you nothing about *why* a call failed to arrive. ## Keeping the suite fast and stable A few rules that hold up across large suites: * **Never sleep.** A sleep pays unconditionally and still asserts at one guessed instant. There is no case where it beats a bounded wait. * **Be generous with deadlines.** Success returns early, so a five-second timeout on a green test costs milliseconds. Tightening timeouts optimises the fast path and buys flakiness with the saving. Loaded CI agents are orders of magnitude slower than a developer laptop at thread scheduling. * **Budget the failure cost.** Deadlines are only paid by failures, but a broken build with fifty waiting tests pays fifty deadlines serially. That, not green-run speed, is the argument for keeping the number of waiting tests small. * **Pair every wait with a positive expectation.** Absence assertions must sit *after* a barrier, never carry a timeout of their own. * **Watch for confined execution.** A wait that blocks the only thread able to run the pending work fails deterministically at the full deadline. Its signature is a failure duration that exactly equals the timeout, on every run. * **Capture worker failures.** Exceptions on background threads do not reach the test, so an uncaught-exception handler that records failures turns "no matching calls" into the real cause. ## The policy I would write down Inject the execution seam for code we own; use a latch-in-a-stub barrier for edges we do not; allow `verify(timeout = ...)` for simple eventual-call assertions with deadlines measured in seconds; ban sleeps outright; and treat a timeout on a negative assertion as a review defect. Then track how many tests need waiting at all — a growing count is a design signal about missing seams, not a testing problem.