synchronizing-with-idle

What problem does it solve?

It eliminates flaky Jetpack Compose UI tests caused by waiting on the wrong synchronization primitive, using wall-clock time where deterministic test-clock progression is required, or reading/mutating Compose state from the wrong thread.

Core Features & Use Cases

• Idle semantics and decision matrix: Defines what “idle” means in Compose tests (recompositions drained, draw ready, and all registered IdlingResources are idle) and helps you pick the correct API among waitForIdle/awaitIdle, waitUntil*, runOnIdle, runOnUiThread, runWhenIdle, awaitAndRunWhenIdle, and hasPendingWork.
• Correct timeout sourcing: Explains the wall-clock vs test-clock split so you use waitUntil for non-Compose conditions and mainClock.advanceTimeUntil for Compose-state-observable conditions.
• Thread-safety guardrails: Prevents stale reads by funneling test-thread state reads through runOnIdle (and correct mutation behavior through runOnUiThread under a paused clock).
• External async synchronization: Shows when and how to register an Espresso/Compose-compatible IdlingResource so HTTP/DB-style work participates in waits reliably.

Quick Start

Use this skill to choose the exact ComposeTestRule/ComposeUiTest wait or idle API for your flaking UI test and fix the timeout source and thread access pattern based on what your condition depends on.