synchronizing-with-idle

Compose UI test flakiness often stems from waiting on the wrong synchronization primitive. You can resolve it by selecting the correct idle-wait API and ensuring timeout sources match whether your condition relies on wall-clock or test-clock progression.

Use waitUntil for non-Compose conditions running on wall-clock time, and use mainClock.advanceTimeUntil for Compose-state-observable conditions. Distinguishing wall-clock waitUntil from test-clock advanceTimeUntil behavior ensures deterministic test-clock progression.

Use runOnIdle to safely read Compose state from the test thread, preventing stale reads. Use runOnUiThread for correct state mutation behavior under a paused test clock, funneling state access safely during assertion-heavy blocks.

To synchronize Compose tests with external async work, register an Espresso and Compose-compatible IdlingResource. This ensures HTTP or DB-style background work reliably participates in idle waits and prevents premature assertions.

In Compose UI testing, idle means all recompositions are drained, the draw is ready, and all registered IdlingResources are idle. Defining idle precisely helps you select the correct API among waitForIdle, awaitIdle, and runWhenIdle.

Yes, you can register an Espresso and Compose-compatible IdlingResource so external async work participates in waits reliably. This integration ensures background tasks like HTTP or DB operations are tracked during Compose test synchronization.