Structuring a Compose Test — The androidx-Canonical Class Skeleton

Compose tests fail or rot because their structure is wrong, not because the assertions are wrong. State that lives inside setContent { } cannot be driven from the test thread; setContent called inside @Before becomes a hidden race; combining @get:Rule with runComposeUiTest { } creates two competing test environments. This skill encodes the exact class skeleton used by androidx.compose.material3 and androidx.compose.foundation so the developer's tests behave the same way.

When to use this skill

• The developer is creating a new *Test.kt and asks where to put state, the rule, and setContent.
• A test compiles but cannot mutate state mid-test ("how do I flip the checkbox after the first assertion?").
• The developer pasted setContent into @Before and the test is now flaky or will not start.
• A reviewer flags a test for declaring state inside setContent { }.
• The developer mixed @get:Rule createComposeRule() and runComposeUiTest { } and gets confusing failures.

When NOT to use this skill

• The developer is choosing which entry point to use (rule vs. runComposeUiTest); use ../../setup/choosing-test-rule-vs-runtest/SKILL.md.
• The build cannot resolve createComposeRule; use ../../setup/configuring-test-dependencies/SKILL.md.
• The decision is host (Robolectric) vs. device (instrumentation); use ../../setup/setting-up-host-vs-device-tests/SKILL.md.
• The test is specifically for a LazyColumn/LazyRow; layer ../testing-lazy-lists/SKILL.md on top of this skeleton.