structuring-a-compose-test

Flaky Compose UI tests often stem from improper state hoisting and mismanaged test rules. Standardizing your test architecture with a single test rule and correct lifecycle management prevents race conditions during UI verification.

To structure a Compose UI test class, use the canonical androidx skeleton with a single test rule declaration. Avoid calling setContent in @Before and ensure proper test method organization to prevent compilation errors.

Correct state hoisting in Compose instrumentation tests involves lifting mutable state above setContent. This allows external driving of UI state, ensuring reliable state mutation and observation within the Compose environment.

The Test-Find-Assert-Act-Re-assert flow is a standardized sequence for Compose UI testing. It enforces finding UI elements, asserting initial state, acting on the UI, and re-asserting to verify reliable state mutation and observation.

Yes, Compose instrumentation tests require a single v2 test rule entry point for AndroidJUnit4. Mixing incompatible test entry points leads to lifecycle mismanagement and flaky UI verification.

No, calling setContent in @Before is a common pitfall in Compose testing. You should use the canonical class skeleton and proper lifecycle best practices to avoid mismanaged test rules and compilation errors.