Setting Up Host vs Device Tests — Pick the Right Source Set

Compose tests run unchanged on either Robolectric (JVM, fast, no emulator) or on a real/virtual device (full Android stack, RenderThread, accessibility). The same runComposeUiTest { setContent { … } } block compiles in both — only the underlying Looper and Choreographer differ. This skill encodes which flavor each test should live in, the Robolectric class skeleton, and the one legitimate Thread.sleep exception (screenshot tests waiting on the RenderThread).

When to use this skill

• The user is starting a Compose UI test and asks "test/ or androidTest/?".
• A test passes on a local emulator but fails on CI's Robolectric runner (or vice versa).
• The user reports Build.FINGERPRINT == "robolectric" warnings from enableAccessibilityChecks(...).
• A screenshot test produces a black/empty PNG on the host runner.
• A ripple/pressInteraction test renders no ripple on Robolectric and the user is debugging why.
• The user wrote Thread.sleep(1000) to "wait for an animation" and is asking why it is flaky.
• The user mentions androidDeviceTest / androidHostTest source sets (used in androidx itself).

When NOT to use this skill

• The dependencies are not yet wired correctly — start with ./configuring-test-dependencies/SKILL.md.
• The choice is between createComposeRule() and runComposeUiTest { } — see ./choosing-test-rule-vs-runtest/SKILL.md.
• The test runs in the right flavor but is flaky on idle/animation — see ../../synchronization/synchronizing-with-idle/SKILL.md and ../../synchronization/testing-animations-deterministically/SKILL.md.