Compose UI testing in Android Kotlin - Build, Publish & Deploy

Build & Publish - Compose UI testing

Performance Impact of Compose UI Testing

Compose UI tests run on the device or emulator and simulate user actions. They do not affect your app's runtime performance but add time to your development cycle. Running many UI tests can slow down your build and test feedback loop. However, they help catch UI bugs early, improving app stability and user experience.

Tests themselves do not impact app frame rate or battery during normal use, but poorly written tests can cause longer test execution times and higher memory use on test devices.

💻

How to Optimize Compose UI Testing for Fast Feedback

• Write focused tests that check one UI behavior at a time.
• Use createComposeRule() to isolate composables and avoid launching full activities.
• Mock dependencies to avoid slow network or database calls during tests.
• Run tests on headless emulators or physical devices with good performance.
• Use runOnIdle and waitForIdle to synchronize UI state efficiently.
• Group tests logically and run critical tests first to catch issues early.

Impact on App Bundle Size and Startup Time

Compose UI testing code is included only in the test APK, not in the production app bundle. Therefore, it does not increase your app's size or affect startup time for users.

However, adding many test dependencies can increase your overall project size and build time. Keep test libraries up to date and remove unused dependencies to keep builds lean.

iOS vs Android Differences for Compose UI Testing

Compose UI testing is specific to Android's Jetpack Compose framework. On iOS, UI testing uses XCTest and SwiftUI testing tools.

Android Compose tests use composeTestRule and Kotlin APIs, while iOS uses Xcode UI test targets with Swift.

Test execution speed and device availability differ: Android emulators can be slower than iOS simulators, but physical devices are comparable.

Relevant Store Review Guidelines and Requirements

• UI tests do not affect app store submission since test code is separate from release builds.
• Ensure your app complies with UI responsiveness and accessibility guidelines to pass store reviews.
• Automated UI tests can help verify accessibility features like content descriptions and focus order.
• Keep test code out of production APKs to avoid accidental exposure of debug information.

Self-Check: Your App Takes 5 Seconds to Load This Screen. What's Likely Wrong?

Possible issues include:

• Tests running full activities instead of isolated composables, causing slow setup.
• Network or database calls not mocked, delaying UI rendering in tests.
• Heavy animations or recompositions blocking the UI thread during tests.
• Not using waitForIdle or synchronization methods, causing flaky or slow tests.

Optimizing test setup and mocking dependencies can speed up UI test execution.

Key Result

Compose UI testing improves app quality without affecting app size or runtime performance. Optimizing tests for speed and isolation ensures fast feedback and stable UI behavior.

Practice

1. What is the main purpose of createComposeRule() in Compose UI testing?

easy

A. To create UI elements dynamically during runtime

B. To set up the environment for testing Compose UI components

C. To launch the app on a physical device

D. To generate random test data for UI tests

Solution

1. Step 1: Understand the role of createComposeRule()

   This function sets up the Compose testing environment so you can test UI components safely and isolated.

2. Step 2: Differentiate from other options

   It does not create UI elements dynamically, launch apps, or generate test data; it only prepares the test rule.

3. Final Answer:

   To set up the environment for testing Compose UI components -> Option B

4. Quick Check:

   Compose test setup = B [OK]

Hint: Remember: createComposeRule sets up Compose test environment [OK]

Common Mistakes:

• Thinking it creates UI elements during app runtime
• Confusing it with launching the app on devices
• Assuming it generates test data automatically

2. Which of the following is the correct way to find a UI element by its text in Compose UI testing?

easy

A. composeTestRule.getElementByText("Hello")

B. composeTestRule.findViewByText("Hello")

C. composeTestRule.selectNode("Hello")

D. composeTestRule.onNodeWithText("Hello")

Solution

1. Step 1: Recall Compose testing API for text search

   The correct method to find a node by text is onNodeWithText().

2. Step 2: Verify other options are invalid

   Methods like findViewByText, getElementByText, and selectNode do not exist in Compose testing.

3. Final Answer:

   composeTestRule.onNodeWithText("Hello") -> Option D

4. Quick Check:

   Find by text = onNodeWithText [OK]

Hint: Use onNodeWithText to find text elements in Compose tests [OK]

Common Mistakes:

• Using Android View testing methods instead of Compose methods
• Trying to use non-existent functions
• Confusing node selectors with view selectors

3. Given this Compose test code snippet:

composeTestRule.setContent {
  Text("Welcome")
}

composeTestRule.onNodeWithText("Welcome").assertExists()

What will happen when this test runs?

medium

A. The test will pass because the text "Welcome" exists

B. The test will fail because the text is not found

C. The test will throw a syntax error

D. The test will pass but not check the text

Solution

1. Step 1: Analyze the UI content set

   The UI contains a Text composable with the string "Welcome".

2. Step 2: Understand the assertion

   assertExists() checks that the node with text "Welcome" is present, which it is.

3. Final Answer:

   The test will pass because the text "Welcome" exists -> Option A

4. Quick Check:

   Text present means assertExists passes [OK]

Hint: assertExists passes if UI text is present exactly [OK]

Common Mistakes:

• Assuming assertExists checks content correctness beyond presence
• Thinking the test fails if no interaction is done
• Confusing syntax errors with runtime test failures

4. Identify the error in this Compose UI test code:

composeTestRule.setContent {
  Button(onClick = {}) {
    Text("Click Me")
  }
}

composeTestRule.onNodeWithTag("button").performClick()

medium

A. performClick() is not a valid Compose test function

B. The Button composable cannot be clicked in tests

C. The node is searched by tag but no tag was set on the Button

D. The Text inside Button should be searched instead of Button

Solution

1. Step 1: Check how the node is found

   The test looks for a node with tag "button" but the Button has no tag set.

2. Step 2: Understand Compose testing tags

   To find by tag, the Button must have Modifier.testTag("button") applied, which is missing.

3. Final Answer:

   The node is searched by tag but no tag was set on the Button -> Option C

4. Quick Check:

   Missing testTag causes node not found [OK]

Hint: Always add testTag modifier to find nodes by tag [OK]

Common Mistakes:

• Assuming performClick works without correct node selection
• Searching text inside Button instead of Button itself
• Thinking performClick is invalid in Compose tests

5. You want to test a Compose screen with a list of items. Each item has a unique test tag like "item_1", "item_2", etc. Which approach correctly verifies that the item with tag "item_3" is displayed and clickable?

hard

A. composeTestRule.onNodeWithTag("item_3").assertIsDisplayed().performClick()

B. composeTestRule.onNodeWithText("item_3").assertIsDisplayed().performClick()

C. composeTestRule.onNodeWithTag("item_3").assertExists().performClick()

D. composeTestRule.onNodeWithContentDescription("item_3").assertIsDisplayed().performClick()

Solution

1. Step 1: Identify correct node selector for test tag

   Use onNodeWithTag("item_3") to find the node by its unique test tag.

2. Step 2: Verify visibility and interaction

   assertIsDisplayed() confirms the node is visible, and performClick() simulates a click.

3. Step 3: Eliminate incorrect options

   Searching by text or content description is wrong here; assertExists() alone doesn't check visibility.

4. Final Answer:

   composeTestRule.onNodeWithTag("item_3").assertIsDisplayed().performClick() -> Option A

5. Quick Check:

   Tag + visible + click = composeTestRule.onNodeWithTag("item_3").assertIsDisplayed().performClick() [OK]

Hint: Use onNodeWithTag + assertIsDisplayed before performClick [OK]

Common Mistakes:

• Using onNodeWithText instead of onNodeWithTag for tags
• Skipping assertIsDisplayed before clicking
• Confusing content description with test tag