Compose UI tests

What a UI test does

A UI test drives your screen like a user: it types into fields, taps buttons and checks what appears. Compose UI tests read the semantics tree (the same tree TalkBack uses), so they find elements by their text, content description or test tag, not by pixel position. They usually live in src/androidTest and run on a device or emulator.

The pieces

A complete test

// The composable under test (stateless, from module 6)
@Composable
fun SignupForm(onSubmit: (String) -> Unit) {
    var mobile by remember { mutableStateOf("") }
    Column {
        OutlinedTextField(mobile, { mobile = it.filter(Char::isDigit).take(10) },
            label = { Text("Mobile number") }, modifier = Modifier.testTag("mobile"))
        Button(onClick = { onSubmit(mobile) }, enabled = mobile.length == 10) { Text("Continue") }
    }
}

// app/src/androidTest/.../SignupFormTest.kt
class SignupFormTest {
    @get:Rule val rule = createComposeRule()

    @Test
    fun continueEnabledOnlyWithTenDigits() {
        var submitted = ""
        rule.setContent { SignupForm(onSubmit = { submitted = it }) }

        rule.onNodeWithText("Continue").assertIsNotEnabled()
        rule.onNodeWithTag("mobile").performTextInput("98765abc43210")
        rule.onNodeWithText("Continue").assertIsEnabled().performClick()

        assertEquals("9876543210", submitted)
    }
}

testTag

When text is not unique or changes with language, give the element a stable test tag with Modifier.testTag("total") and find it with onNodeWithTag. Tags do not affect what users see. Keep them as constants so tests and UI use the same string.

Synchronisation

Compose tests automatically wait until the UI is idle (no pending recompositions or animations) before each finder and assertion, so you rarely need waits. For work outside Compose's knowledge, rule.waitUntil { condition } waits for a condition with a timeout. Never use Thread.sleep in tests.

Test stateless content

UI tests are easiest on stateless composables that take state and lambdas (the "Content" pattern from module 7). You can show any state, even rare error states, without a real ViewModel, server or database, and check that the UI shows the right thing.

Because finders use semantics, good accessibility and good testability go together: a button with a clear contentDescription is easy for TalkBack and easy for tests.

Espresso, briefly

Older apps built with XML Views use Espresso for UI tests (onView(withId(R.id.pay)).perform(click())). Compose and Espresso can be mixed in apps that contain both kinds of UI. New Compose code should use the Compose testing APIs.

Common mistakes

• Finding by text that will be translated, so tests fail in Hindi. Use test tags or string resources.
• Testing through the whole app (login, navigation) just to check one button. Set the composable directly.
• Using Thread.sleep instead of letting Compose synchronise.
• Too many slow UI tests for logic that a unit test could cover.