Android UI Testing with Espresso: Development, Stability, CI

Developing UI Tests for Android Apps (Espresso)

You wrote a login screen in Compose, set up Hilt, added Retrofit. You run the test — it fails. Why? Android UI tests are often flaky — the root cause is almost always ignoring IdlingResource. Developers insert Thread.sleep(2000) and hope it passes — that's a path to chaos. Without properly configured IdlingResource, stability rarely exceeds 60%. A test suite of 100+ tests requires 2–3 hours to run, half fail due to timing.

We offer turnkey Espresso UI test development. We design architecture with the Robot pattern, configure IdlingResource for all asynchronous operations, and integrate with Firebase Test Lab. Within 3–5 days you get a stable set of critical user flows (login, payment, core UX). One of our projects — an internet banking app with 1,200 tests — achieved 98.5% stability after IdlingResource tuning.

Google officially recommends using IdlingResource to synchronize tests with background tasks — it's the foundation of stable automated testing.

Fundamentals and Critical Nuances

The basic Espresso test structure: onView(matcher).perform(action).check(assertion).

@Test fun loginWithValidCredentials_navigatesToHome() { onView(withId(R.id.emailInput)) .perform(typeText("[email protected]"), closeSoftKeyboard()) onView(withId(R.id.passwordInput)) .perform(typeText("password123"), closeSoftKeyboard()) onView(withId(R.id.loginButton)) .perform(click()) onView(withId(R.id.homeTitle)) .check(matches(isDisplayed())) } 

The most common cause of flaky tests is IdlingResource. If the app performs an asynchronous request (Retrofit, Coroutine), Espresso is unaware and tries to find the next element before the operation completes. The solution — register an IdlingResource.

// For OkHttp/Retrofit use OkHttpIdlingResource val idlingResource = OkHttpIdlingResource.create("okhttp", okHttpClient) IdlingRegistry.getInstance().register(idlingResource) // For coroutines use EspressoIdlingResource IdlingRegistry.getInstance().register(EspressoIdlingResource.getIdlingResource()) 

Espresso runs 2–3 times faster than UIAutomator because it avoids sleep.

Why Do Espresso Tests Fail?

Besides IdlingResource, a common issue is race conditions when working with RecyclerView or multithreading. Use IdlingResource for asynchronous operations and CountingIdlingResource for background tasks. In our experience, after implementing IdlingResource, test stability jumps from 60% to 95%.

Jetpack Compose UI Testing

If the project uses Compose, the Espresso approach is replaced by ComposeTestRule:

@get:Rule val composeTestRule = createAndroidComposeRule<MainActivity>() @Test fun loginScreen_showsErrorOnInvalidEmail() { composeTestRule.onNodeWithTag("emailInput") .performTextInput("invalid-email") composeTestRule.onNodeWithTag("loginButton") .performClick() composeTestRule.onNodeWithText("Invalid email format") .assertIsDisplayed() } 

testTag in Compose — the equivalent of accessibilityIdentifier in iOS. We always assign tags to all testable elements using Modifier.testTag("loginButton").

How to Speed Up Test Writing?

We use the Robot pattern — the Compose equivalent of Page Object. It makes tests read like scenarios and simplifies refactoring. Comparison:

Robot pattern is a better fit for Compose projects. Example:

class LoginRobot(private val composeTestRule: AndroidComposeTestRule<*, *>) { fun enterEmail(email: String) = apply { composeTestRule.onNodeWithTag("emailInput").performTextInput(email) } fun enterPassword(password: String) = apply { composeTestRule.onNodeWithTag("passwordInput").performTextInput(password) } fun clickLogin() = apply { composeTestRule.onNodeWithTag("loginButton").performClick() } fun assertHomeVisible() { composeTestRule.onNodeWithTag("homeScreen").assertIsDisplayed() } } // Test reads like a scenario @Test fun validLogin_showsHome() { LoginRobot(composeTestRule) .enterEmail("[email protected]") .enterPassword("pass123") .clickLogin() .assertHomeVisible() } 

Hilt and DI in Instrumented Tests

If the project uses Hilt, tests require HiltAndroidRule. The @BindValue annotation allows replacing a real repository with a fake without modifying production code — the test doesn't depend on the network or database.

How to Write a Stable Espresso Test in 5 Steps

1. Define the scenario and identify asynchronous operations.
2. Register IdlingResource for each operation.
3. Use Robot pattern for structuring.
4. Run the test locally, verify stability.
5. Integrate with CI and Firebase Test Lab.

CI: Firebase Test Lab

A local emulator is sufficient for development, but before release — Firebase Test Lab with real devices. Example workflow (GitHub Actions):

- name: Run Espresso tests on Firebase Test Lab run: | gcloud firebase test android run \ --type instrumentation \ --app app/build/outputs/apk/debug/app-debug.apk \ --test app/build/outputs/apk/androidTest/debug/app-debug-androidTest.apk \ --device model=Pixel8,version=34 \ --device model=GalaxyS23,version=33 

Results — Logcat, screenshots on failure, run video — are stored in Google Cloud Storage. CI setup is included in the scope of work.

What's Included in Espresso UI Test Development

• Designing test architecture (pattern selection, IdlingResource configuration)
• Writing critical user flows (login, payment, core UX) with Robot pattern
• CI/CD integration (GitHub Actions, Firebase Test Lab)
• Documentation for running and maintaining tests
• Team training (1–2 hour workshop)

We have developed UI tests for 15+ Android apps, average stability — 97%, largest project — 1,200 tests. Average run time for 100 tests — 15 minutes compared to 2 hours without optimization.

Timeline: from 3 to 10 days depending on app complexity. Pricing is individual. If you need help with implementation — contact us, we'll conduct an audit and propose a solution. Order development of a test suite — we guarantee >95% stability and one month of support.