Compose: UI testing patterns

Core principle

Test the smallest UI contract that proves the behavior. Prefer plain state-driven UI tests with callbacks. Add integration only when lifecycle, navigation, DI, or platform behavior is the thing under test.

Procedure

1. State the behavior and test concern the task asks you to prove.
2. Inspect the existing test against that concern and choose the smallest sufficient seam from the table below.
3. Keep focused edits within the requested test concern. Do not move test-only helpers into production or broaden production APIs unless that production boundary is itself under test.
4. Drive controlled state or input, synchronize through Compose when needed, and assert an observable semantic, visual, or callback result.
5. Finish with no edit when the existing test already uses the narrowest valid seam and proves the requested behavior.

Test target choice

What you need to prove	Test shape
Text, button, loading/error branch, conditional content	Plain UI Compose test
Callback wiring from click/input	Plain UI Compose test
Focus navigation or keyboard behavior	Compose test with key input
Visual layout, clipping, elevation, typography, image composition	Screenshot test
State holder updates UI correctly	State holder/unit test plus one wiring smoke test
Hover, pressed, focused, dragged interaction state	Plain UI test with MutableInteractionSource
Navigation, lifecycle, DI integration	Integration test

Prefer plain UI tests

If the screen has a state holder/UI split, test the plain UI composable:

composeTestRule.setContent {
    ProfileScreen(
        state = ProfileUiState(name = "Ada", canSave = true),
        onNameChange = {},
        onSaveClick = { saved = true },
        onBackClick = {},
    )
}

composeTestRule.onNodeWithText("Ada").assertIsDisplayed()
composeTestRule.onNodeWithText("Save").performClick()