Synchronizing With Idle — Pick the Right Wait

A Compose test that waits on the wrong primitive is the #1 source of flakiness. This skill enumerates every idle/wait API on ComposeTestRule and ComposeUiTest, locks down what "idle" actually means, and gives a decision matrix for choosing among them. Animation-specific waits live in ../testing-animations-deterministically/SKILL.md; the underlying clock semantics live in ../controlling-the-test-clock/SKILL.md.

When to use this skill

• The test occasionally fails with "node not found" or "node count mismatch" but the production code is correct.
• The developer reaches for Thread.sleep(2000) to wait for a screen, a snackbar, a navigation transition, or an IO-backed state.
• A ViewModel posts state from a coroutine and the test needs to wait until the UI reflects it.
• The developer asks about IdlingResource, the Espresso bridge, runOnIdle vs runOnUiThread, or whether runWhenIdle is faster.
• The developer mentions waitUntil, waitUntilExactlyOneExists, waitUntilNodeCount, AndroidComposeUiTestTimeoutException, or IdlingPolicies.setMasterPolicyTimeout.
• The developer reads or mutates state from the test thread (e.g. state.firstVisibleItemIndex) and asks why it sometimes returns stale data.

When NOT to use this skill

• The condition is a paused-clock animation. Use ../testing-animations-deterministically/SKILL.md and mainClock.advanceTimeUntil.
• The mechanics of MainTestClock itself (frames, rounding, dispatchers) are unclear. Read ../controlling-the-test-clock/SKILL.md first.
• The test is failing because of test-tag/finder issues, not async timing. Use ../../debug/printing-the-semantics-tree/SKILL.md and ../../finders/finding-nodes-by-tag-text-content/SKILL.md.
• Espresso interop is the actual question. Use ../../interop/testing-with-espresso-interop/SKILL.md (sibling skill, separate scope).