Automated Tests for Your App

You have built apps that work. But how do you know they work? So far the answer has been "I ran it and tapped around". That is fine for a first app, and a disaster for a real one. Imagine an app with fifty screens. After every change you would need to tap through all fifty to be sure you broke nothing. Nobody does that, so bugs slip out.

Automated tests are small programs that check your app for you, in seconds, as often as you like. In this lesson you will write your first ones for a tip calculator: local unit tests that check calculations, and Compose UI tests that check what the user sees.

This lesson covers the Write automated tests codelab in Unit 2 of Google's official Android Basics with Compose course.

By the end you will be able to:

• Explain why automated tests exist and what a "test" really is.
• Tell local tests (the test folder) from instrumented tests (the androidTest folder).
• Write a JUnit test using the Arrange, Act, Assert pattern.
• Avoid the locale trap that breaks currency tests on other people's computers.
• Write a Compose UI test that types into text fields and checks the screen.
• Run tests in Android Studio and from the command line, and read the results.

Mindset: a test is a question you ask your code that has a known answer. "If the bill is 10 and the tip is 20 per cent, is the tip 2?" If the code answers anything else, the test fails and tells you exactly where.

• Functions with parameters and defaults (lesson 8). Our calculator is a function with default arguments.
• State and text fields (lesson 19). The UI test types into text fields that update state.
• Gradle dependencies (lesson 03). Tests need libraries, declared in build.gradle.kts and the version catalog libs.versions.toml.
• Annotations such as @Test and @Composable. An annotation is a label that tells a tool how to treat the code beneath it.

The code under test

To keep this lesson self-contained, here is the calculation we will test. If you built the tip calculator in lesson 19 your function is probably very similar. Use this version so the tests below match exactly.

package com.example.tipcalculator
import java.text.NumberFormat
/**
 * Returns the tip as formatted currency text, for example "$2.00".
 * [tipPercent] is a percentage, so 20.0 means 20 per cent.
 */
fun calculateTip(
 amount: Double,
 tipPercent: Double = 15.0,
 roundUp: Boolean = false
): String {
 var tip = tipPercent / 100 * amount
 if (roundUp) {
 tip = kotlin.math.ceil(tip)
 }
 return NumberFormat.getCurrencyInstance().format(tip)
}

Read it once. It multiplies, optionally rounds up to the next whole currency unit with ceil, and formats the result for the user's locale. That last step is important for a trap we reach shortly.

The test pyramid

Different tests cost different amounts. A healthy project has many cheap tests and a few expensive ones:

          /\
         /UI\          few: slow, need an emulator or phone
        /----\
       / unit \        many: fast, run on your computer only
      /--------\

Rule of thumb: if the code does not need Android, test it as a local unit test. It is faster, and you will actually run it.

Anatomy of a test: Arrange, Act, Assert

Every good test has three parts, and naming them makes tests easy to write and read:

1. Arrange the situation: create inputs and expected results.
2. Act: call the code you are testing.
3. Assert: compare the actual result with the expected one.

A test passes when all assertions hold and fails when one does not. A failing test is not bad news. It is the test doing its job.

Why tests are worth the effort

• They catch regressions: an old feature quietly breaking when you add a new one.
• They are documentation: each test is a worked example of how the function behaves.
• They let you refactor without fear: change the insides, run the tests, trust the green ticks.
• They force you to design code that is easy to test, which is usually easier to understand too.

Switch the Project tool window to Project view (not Android view) and look inside app/src. You will see three folders: main (your app), test (local tests) and androidTest (instrumented tests). The template already created a sample test file in each of the last two.

The Empty Activity template also adds the testing libraries. In app/build.gradle.kts look for lines like these in the dependencies block (the exact names depend on your template version):

dependencies {
 // ... app dependencies ...
 testImplementation(libs.junit)
 androidTestImplementation(libs.androidx.junit)
 androidTestImplementation(libs.androidx.espresso.core)
 androidTestImplementation(platform(libs.androidx.compose.bom))
 androidTestImplementation(libs.androidx.ui.test.junit4)
 debugImplementation(libs.androidx.ui.tooling)
 debugImplementation(libs.androidx.ui.test.manifest)
}

What each line does:

• testImplementation makes a library available only to local tests. junit is the testing framework.
• androidTestImplementation makes a library available only to instrumented tests. ui-test-junit4 gives you createComposeRule() and the finders.
• debugImplementation(libs.androidx.ui.test.manifest) is required for Compose UI tests: it adds a manifest entry that lets the test activity launch. If you forget it, UI tests fail with a confusing "no activity" error.

The matching entries live in gradle/libs.versions.toml. Never type version numbers from a tutorial blindly. Use the versions the template gives you, or ask Android Studio to suggest updates.

Create the test file

1. In the Android view, expand com.example.tipcalculator (test).
2. Right-click it, choose New > Kotlin Class/File, and name it TipCalculatorTests.
3. Write the test:

package com.example.tipcalculator
import org.junit.Assert.assertEquals
import org.junit.Test
import java.text.NumberFormat
class TipCalculatorTests {
 @Test
 fun calculateTip_20PercentNoRoundup() {
 // Arrange
 val amount = 10.00
 val tipPercent = 20.00
 val expectedTip = NumberFormat.getCurrencyInstance().format(2)
 // Act
 val actualTip = calculateTip(amount = amount, tipPercent = tipPercent, roundUp = false)
 // Assert
 assertEquals(expectedTip, actualTip)
 }
}

Line by line

• @Test tells JUnit "this function is a test, run it".
• The name calculateTip_20PercentNoRoundup follows the convention functionName_scenario. When it fails, the name alone explains what broke.
• assertEquals(expected, actual) passes when both are equal. Always put the expected value first, because failure messages assume that order.
• NumberFormat.getCurrencyInstance().format(2) is the locale trap solution. If you wrote the literal "$2.00" and a teammate in Nigeria ran the test with a Naira locale, the actual result would be ₦2.00 and the test would fail for a reason unrelated to your code. Building the expected text with the same formatter makes the test pass everywhere.

Run it

Click the green triangle beside the class name or function and choose Run 'TipCalculatorTests'. The Run window shows a green tick and a summary such as 1 test passed. It finishes in under a second because nothing needs the emulator.

Make it fail on purpose

Change expectedTip to format(3) and run again. The failure message tells you something like expected:<$3.00> but was:<$2.00>. Learning to read these messages is half of testing. Change it back.

More tests

One test proves little. Add a second that exercises rounding:

 @Test
 fun calculateTip_15PercentWithRoundup() {
 val expectedTip = NumberFormat.getCurrencyInstance().format(2)
 val actualTip = calculateTip(amount = 10.00, tipPercent = 15.00, roundUp = true)
 assertEquals(expectedTip, actualTip)
 }
 @Test
 fun calculateTip_defaultPercentIsFifteen() {
 val expectedTip = NumberFormat.getCurrencyInstance().format(1.5)
 val actualTip = calculateTip(amount = 10.00)
 assertEquals(expectedTip, actualTip)
 }

Check the arithmetic: 15 per cent of 10 is 1.5, rounded up it is 2. And with the default of 15 per cent and no rounding, the tip is 1.5. Each test uses named arguments so the call explains itself.

Local tests cannot see the screen. To test what the user sees, you write an instrumented UI test that launches your composable on a device or emulator, performs actions and checks the result.

A screen worth testing

Here is a minimal tip screen. It has two text fields, a Switch and a result line. Put it in TipScreen.kt in main:

package com.example.tipcalculator
import androidx.compose.foundation.layout.Column
import androidx.compose.foundation.layout.padding
import androidx.compose.foundation.text.KeyboardOptions
import androidx.compose.material3.OutlinedTextField
import androidx.compose.material3.Switch
import androidx.compose.material3.Text
import androidx.compose.runtime.Composable
import androidx.compose.runtime.getValue
import androidx.compose.runtime.mutableStateOf
import androidx.compose.runtime.remember
import androidx.compose.runtime.setValue
import androidx.compose.ui.Modifier
import androidx.compose.ui.text.input.KeyboardType
import androidx.compose.ui.unit.dp
@Composable
fun TipScreen(modifier: Modifier = Modifier) {
 var amountInput by remember { mutableStateOf("") }
 var percentInput by remember { mutableStateOf("") }
 var roundUp by remember { mutableStateOf(false) }
 val amount = amountInput.toDoubleOrNull() ?: 0.0
 val percent = percentInput.toDoubleOrNull() ?: 0.0
 val tip = calculateTip(amount, percent, roundUp)
 Column(modifier = modifier.padding(16.dp)) {
 OutlinedTextField(
 value = amountInput,
 onValueChange = { amountInput = it },
 label = { Text("Bill Amount") },
 keyboardOptions = KeyboardOptions(keyboardType = KeyboardType.Number)
 )
 OutlinedTextField(
 value = percentInput,
 onValueChange = { percentInput = it },
 label = { Text("Tip Percentage") },
 keyboardOptions = KeyboardOptions(keyboardType = KeyboardType.Number)
 )
 Switch(checked = roundUp, onCheckedChange = { roundUp = it })
 Text(text = "Tip Amount: $tip")
 }
}

Write the UI test

Create TipUiTests.kt in the androidTest folder (com.example.tipcalculator (androidTest)):

package com.example.tipcalculator
import androidx.compose.ui.test.junit4.createComposeRule
import androidx.compose.ui.test.onNodeWithText
import androidx.compose.ui.test.performTextInput
import org.junit.Rule
import org.junit.Test
import java.text.NumberFormat
class TipUiTests {
 @get:Rule
 val composeTestRule = createComposeRule()
 @Test
 fun calculate_20_percent_tip() {
 composeTestRule.setContent {
 TipScreen()
 }
 composeTestRule.onNodeWithText("Bill Amount").performTextInput("10")
 composeTestRule.onNodeWithText("Tip Percentage").performTextInput("20")
 val expectedTip = NumberFormat.getCurrencyInstance().format(2)
 composeTestRule.onNodeWithText("Tip Amount: $expectedTip").assertExists(
 "No node with this text was found."
 )
 }
}

How it works

• createComposeRule() creates a rule: a helper JUnit runs around every test. It launches an empty activity and gives you setContent.
• setContent { TipScreen() } shows only the composable you are testing, with no navigation or theme noise. Testing a composable in isolation keeps tests fast and focused.
• onNodeWithText("Bill Amount") is a finder. Compose builds a semantics tree describing the screen for accessibility and testing, and finders search that tree. Here we find the node whose text is the label.
• performTextInput("10") is an action: it types into the field.
• assertExists(...) is an assertion: it fails with your message if no node matches.

Start an emulator (lesson 04), then run the test with the green triangle. The emulator flashes your screen for a moment, types the numbers, and the Run window reports a pass.

Preview of lesson 45: Compose testing has much more: tags, useUnmergedTree, waiting for async work, and debugging flaky tests. Here you learned the shape; there you will master it.

Run all local tests before every commit. Because they are fast, you will not mind.

Mistake #1: Hard-coding currency text. The wrong code: assertEquals("$2.00", actual). What happens: it passes on your laptop and fails on a colleague's with a different locale. The fix: build the expected text with NumberFormat.getCurrencyInstance() or pass a fixed Locale into the function.

Mistake #2: Putting plain logic tests in androidTest. What happens: they need an emulator and take ten times longer, so you stop running them. The fix: anything that does not need Android belongs in test.

Mistake #3: Swapping expected and actual. What happens: the test still passes or fails correctly, but the failure message is backwards and confusing. The fix: assertEquals(expected, actual), always in that order.

Mistake #4: Forgetting ui-test-manifest. What happens: UI tests crash with a message about being unable to find an activity. The fix: add debugImplementation(libs.androidx.ui.test.manifest).

Mistake #5: Testing the wrong thing. The wrong test: checking that a private variable has a certain value. The fix: test behaviour the user can observe, such as the text on the screen or the return value, not internal details that may change.

Mistake #6: One giant test. What happens: when it fails you do not know which part broke. The fix: small tests, one behaviour each, named by function_scenario.

Mistake #7: Tests that depend on each other. What happens: they pass in one order and fail in another. The fix: every test builds its own inputs and never relies on leftovers from another test.

Mistake #8: Ignoring a failing test. The fix: a red test means either the code or the test is wrong. Fix one of them immediately. A test suite people ignore is worse than none.

Question 1. What is the difference between a local unit test and an instrumented test?

Question 2. What are the three parts of a well-structured test?

Question 3. Why is assertEquals("$2.00", actual) risky in a currency test?

Question 4. What does createComposeRule() give you, and why test a composable in isolation?

Question 5. How do you find a Switch that has no text in a UI test?

Go deeper: official resources

• Android Basics with Compose, Unit 2, Pathway 3: Interacting with UI and state: the official pathway containing the Write automated tests codelab.
• Android Basics with Compose course page: all units in order.
• Testing codelab for Jetpack Compose: the advanced Compose testing you will study in lesson 45.
• Jetpack Compose for Android developers, pathway 4: Accessibility, testing and performance: where testing is explored further.