structuring-a-compose-test

To avoid flaky Jetpack Compose UI tests, hoist mutableStateOf above setContent and perform all cross-frame reads and writes using rule.runOnIdle. This ensures the test correctly drives state mutations and re-asserts reliably.

Mixing createComposeRule with runComposeUiTest causes failure because they are incompatible entry points. You must use exactly one v2 compose rule, such as createComposeRule or createAndroidComposeRule, and avoid mixing it with @get:Rule.

To test a Compose screen requiring a custom Activity, use createAndroidComposeRule<MyActivity>() instead of the default rule. This is necessary when the screen-under-test is not backed by a default ComponentActivity.

You should call setContent inside the @Test method rather than in @Before. Calling setContent in @Before is an incompatible pattern that disrupts the composition lifecycle and leads to unstable test behavior.

A canonical AndroidX Compose test class requires @RunWith(AndroidJUnit4::class) and an appropriate size annotation like @MediumTest. This combination ensures the instrumentation test runs with the correct lifecycle and size constraints.

The correct workflow for Compose UI testing is Test, Find, Assert, Act, and Re-assert. After hoisting mutable state above setContent, you mutate it via rule.runOnIdle and re-assert to verify the UI responds correctly.