A large Kotlin test suite has accumulated dozens of Kotest `eventually` and `continually` calls, and CI time and flakiness are both climbing. How would you decide where polled assertions belong at all, and what policy would you set for their budgets?

## Why this becomes a real problem `eventually` is the easiest tool in the box to overuse. It reliably turns a red test green, so it spreads: someone adds it to fix a race, the next person copies the pattern, and within a year the suite has a hundred polls with durations ranging from 500ms to 60s chosen by whoever was debugging that day. The symptoms are predictable — CI wall time creeping up, flakiness that moves rather than disappears, and failures that all look like timeouts regardless of cause. The response is not "ban `eventually`". It is a hierarchy of options with polling near the bottom, plus a small amount of policy for the cases that legitimately need it. ## The hierarchy ### 1. Remove the asynchrony from the test Most polling in a typical suite exists because the code under test made time or dispatch implicit. Common fixes: - Inject the clock rather than reading it globally, so "after 30 minutes" is a value you set, not a wait. - Give the asynchronous component a way to report completion — a returned handle, a callback — instead of forcing observers to guess. - In tests, wire the background worker to run inline where that does not invalidate what you are testing. Each of these deletes a wait entirely. Nothing you can do to a poll's configuration is as valuable. ### 2. Await an explicit signal Where the boundary can tell you it is done, await that. Waiting on a signal is exact; polling is a guess about how long exact would have taken. ### 3. Poll, deliberately What is left is real: a broker actually delivers asynchronously, a container actually takes time to become healthy, a browser actually renders later. Here `eventually` is the right tool and should be used with intent rather than reflex. ## Policy for the remainder **Shared budgets, not scattered numbers.** Define a couple of named configurations — say a fast in-process profile with a short deadline and tight interval, and an infrastructure profile with a longer deadline, an initial delay and a backing-off interval. Every call site references one. When CI moves to slower hardware, you change two values; when someone wants a bespoke 90-second budget, that is a reviewable exception rather than an invisible one. **Narrow the polled scope.** Poll for the one condition that is genuinely asynchronous, take the value `eventually` returns, and assert the rest outside the loop. Wide blocks make real bugs cost the full deadline and blur the failure message. **Narrow the retryable exceptions.** With the default "retry everything", a `NullPointerException` in the test itself looks exactly like a slow dependency. Declaring the expected exception types turns test bugs into instant stack traces and keeps the timeout meaning what it says. **Ration `continually`.** It never finishes early, so every use is a fixed tax on every run. Reserve it for negative assertions that genuinely matter — no duplicate processing, no premature firing — and keep the windows short. Ten `continually(5.seconds)` calls are almost a minute of deliberate idling per build. **Never put triggers inside polls.** This is a review rule, not a preference: a state-changing call inside a polled block executes once per attempt, producing tests whose failures are self-inflicted. ## Measurement — the part teams skip Budgets rot silently because a poll that takes longer still passes. Two signals are worth collecting: 1. **Total time spent in polled assertions per run.** This is the direct cost, and it should be a number someone looks at rather than an emergent property of the suite. 2. **Headroom per call site.** A poll that habitually succeeds at 90% of its deadline is one bad CI day from red. That is the moment to fix the underlying determinism, not to double the deadline. Doubling deadlines is the default reflex and it is almost always the wrong one: it converts an intermittent, informative failure into a slow, permanent cost and defers the diagnosis indefinitely. ## Where reasonable people disagree - **Strict determinism vs realism.** Making everything synchronous in tests can hide genuine ordering bugs that only appear with real dispatch. A common compromise: deterministic unit and module tests, a small number of realistic end-to-end tests where polling is expected and budgeted. - **Retry-on-failure at the runner level.** Some teams accept automatic retries for a quarantined subset to keep the pipeline usable. Defensible only if quarantine is visible and time-boxed; otherwise it silently normalises flakiness. - **One global budget vs per-boundary budgets.** A single number is simpler; per-boundary numbers (broker vs container vs HTTP) are more honest about latency profiles. Either beats ad-hoc. ## The stance to express in an interview Polled assertions are a debt instrument. They are the correct tool at a small number of genuinely asynchronous boundaries, and a smell everywhere else. The engineering work is deleting the ones that should not exist and giving the survivors shared, measured budgets — not tuning durations one failure at a time.