Testing Compose Apps

What you'll learn

Automated tests are what let you change code with confidence — they catch regressions before your users do. The clean architecture you've built (ViewModels, repositories behind interfaces, stateless composables) was designed to be testable. Now let's reap that reward with two kinds of tests.

By the end you'll be able to:

• Explain why automated testing matters
• Unit-test a ViewModel with a fake repository
• Write a Compose UI test with createComposeRule
• Find nodes and assert on them

Why test

Manual testing — tap through the app after every change — is slow, boring, and easy to skip. Automated tests run in seconds, every time, and never forget an edge case. They document how your code is meant to behave and, most importantly, give you the courage to refactor: if the tests still pass, you didn't break anything. There are two levels you'll write most:

Unit-testing a ViewModel

Because a ViewModel takes its dependencies via the constructor, you inject a fake repository — no database, no network — call a function, and assert the resulting state. Coroutines are made deterministic with runTest:

class CounterViewModelTest {
    @Test
    fun increment_increasesCount() = runTest {   // runTest drives coroutines
        val viewModel = CounterViewModel(FakeRepository())

        viewModel.increment()

        assertEquals(1, viewModel.count.value)
    }
}

Compose UI tests

Compose has a first-class testing API. createComposeRule() lets you render a composable in isolation, then interact with it and assert on what's shown. Every UI test follows the same rhythm — set content, assert, act, assert:

class CounterScreenTest {
    @get:Rule val composeRule = createComposeRule()

    @Test
    fun tappingButton_incrementsDisplayedCount() {
        // 1) Set the content under test.
        composeRule.setContent { CounterScreen() }

        // 2) Assert the starting state.
        composeRule.onNodeWithText("Count: 0").assertIsDisplayed()

        // 3) Act — find the button and click it.
        composeRule.onNodeWithText("Increment").performClick()

        // 4) Assert the new state.
        composeRule.onNodeWithText("Count: 1").assertIsDisplayed()
    }
}

Finders & assertions

UI tests work against the semantics tree — the same accessibility information screen readers use, which is why good contentDescriptions help tests too. You find a node, then act or assert on it:

When text isn't stable or unique, add a Modifier.testTag("…") as a reliable hook for the test to find:

Button(
    onClick = onSubmit,
    modifier = Modifier.testTag("submit_button"),   // stable hook for tests
) { Text("Log in") }

// In the test:
composeRule.onNodeWithTag("submit_button").performClick()

Recap & quick check

Your app is tested and trustworthy. The last professional step: handling permissions and publishing to the Play Store.