Across a large suite, when is waiting inside a mock verification the right tool at all, versus a sign the production code should expose a seam that makes the test deterministic? How would you set that policy for a team?

## The decision that matters Every timed mock verification is a bet on machine speed. The engineering question is not which API to use but whether the test should be making that bet at all. Sort each case by asking: if the runtime were infinitely fast, would this test still be interesting? If yes, the asynchrony is incidental and should be designed out of the test. If the interesting part is exactly 'this happens later, in this order, at most this often', the asynchrony is the subject and waiting is honest. ## Designing the asynchrony out The standard seam is to stop constructing execution strategy inside a class. Inject an Executor, a ScheduledExecutorService, a Clock, or a framework task executor. In tests, pass a direct executor (Runnable::run) so submitted work completes before submit returns, a deterministic scheduler that advances virtual time on command, or a fixed Clock. Reactive and coroutine stacks have equivalents (test schedulers, virtual time). The payoff is large: the test asserts the same behaviour with plain verify, runs in microseconds, cannot flake, and fails with a real stack trace instead of a wait timeout. The cost is one more constructor parameter and the discipline to keep production wiring in one place. ## Where waiting earns its place Some contracts cannot be collapsed. A broker listener genuinely delivers on another thread; a retry policy is defined in wall-clock terms; a batcher flushes on a timer; a component under test wraps a third-party library that owns its threads. For those, timed verification is the right instrument, but sized deliberately: timeouts are upper bounds and should be generous, because a passing run pays only the real latency, while a tight budget converts every slow runner into a red build. Full-wait after windows are the opposite — every millisecond is paid on every run — so they should be short, rare, and justified. ## Absence is the expensive claim Asserting that something did not happen is the only assertion that must burn time by construction, and its confidence is bounded by the window. At suite scale these dominate the wall clock and quietly degrade as people shorten windows to speed up CI. Push teams to convert absence assertions into positive terminal signals: drive the pipeline to a completion barrier, then use verifyNoInteractions or verifyNoMoreInteractions with no waiting at all. ## Making the policy stick A policy only works if it is mechanical. Ban Thread.sleep in test sources with a static-analysis rule. Require wait budgets to be named constants so their aggregate is greppable and tunable in one place. Require every test that starts threads to shut them down, since leaked pools cause cross-test flakes that look like timing bugs. Refuse blanket retry-on-failure in CI: it hides the failure class where the async task threw and was swallowed, which is a product bug. Instead quarantine flakes with a named owner and a deadline. ## Reviewing the tradeoff There is a real counter-argument to full determinism: a direct executor changes the concurrency shape, so it will not catch races, visibility bugs, or ordering assumptions that only appear with real threads. The answer is layering — deterministic unit tests for logic, plus a small number of genuinely concurrent tests (and, where it pays, stress or property tests) at the integration layer where the timed verification lives. The policy is not 'never wait'; it is 'wait in few, well-chosen places, generously, and never by sleeping'.