waitUntil

Suspends until condition returns true, driving frames between checks.

Prefer awaitIdle followed by a plain assertion wherever it suffices: it is fully deterministic. Use waitUntil only when a settled condition cannot be expressed that way (e.g. work gated on genuinely external timing).

Bounded by BOTH a frame cap and the timeout wall-clock deadline; whichever trips first fails with an AssertionError that includes a tree dump. The frame cap counts only frames the composition consumes, keeping CI deterministic: a condition gated on a recomposition or frame-effect loop that never becomes true fails after a fixed number of frames regardless of machine speed, while a condition gated on external timing (e.g. a native window-system event) keeps being polled until the wall-clock deadline.

Frames are sent only while MainTestClock.autoAdvance is on. With it off the test owns the frames, so this gate sends none and consumes none of its cap: each poll publishes pending snapshot writes and dispatches queued event-dispatch-thread work - leaving a coroutine parked in withFrameNanos exactly where it is - until the condition holds or the deadline passes.

A failure the library itself raises on the event dispatch thread fails this call the same way awaitIdle does.

Parameters