Manual testing catches many problems but it does not scale well. A tester can tap through an app for an hour and still miss a regression in a rarely used screen. An automated UI test taps through the same flows every time with the same steps. It runs fast and it runs the same way on every build. That consistency makes it a powerful tool for Android teams.
Automated UI tests simulate user actions such as taps and text entry and scrolling. They check that the expected screen appears and that the expected text shows. They can run on an emulator or on a real device. They can run in continuous integration after every code change. A failing test then blocks a bad build before it reaches users.
This guide shows how to automate mobile app UI tests for your own Android apps. It focuses on stable test design rather than on a single tool. Tool names change but the principles of stable selectors and isolated tests and clear assertions stay useful across tools. Start small and grow the suite as the team gains confidence.
Choosing what to automate first
Automate the flows that users use most often first. Login and main navigation and core creation flows deserve automation before edge cases. Those flows break most often during refactoring and they matter most to users. A small suite that covers core flows gives more value than a large suite that covers rare screens with flaky tests.
Avoid automating flows that depend on external services that you cannot control. A test that needs a live payment gateway or a live social login will fail for reasons outside your code. Use test doubles or a staging environment for those flows. A test should fail only when app code breaks and not when an external service has a bad day.
Keep each test focused on one user goal. A test that logs in and creates a note and shares it and deletes it does too much. A failure in that test could come from any step. Split the flow into smaller tests that each check one goal. Smaller tests run faster and their failures point to a specific feature.
Writing stable UI tests
Stable tests use stable selectors. A selector based on a content description or a test tag survives a visual redesign better than a selector based on screen position. Add test tags to key interface elements during development. That small habit makes tests robust and it helps accessibility tooling as well.
Avoid fixed sleep times in tests. A sleep of two seconds may be enough on a fast device and too short on a slow device. Use waits that check for a condition such as an element becoming visible. A condition based wait adapts to device speed and it makes tests faster on fast devices. Fixed sleeps make tests slow and still flaky.
Isolate tests from each other. Each test should set up its own data and clean up after itself. A test that depends on data from a previous test will fail when run alone. A test that leaves data behind can break the next test. Isolation lets the team run a single test for debugging without running the whole suite.
Start a new UI test by recording the exact tap sequence for one core flow on a clean test account. Then rewrite that sequence as a short test that uses test tags and condition based waits for every screen change. Run the new test ten times on the same emulator image and keep it only when it passes ten times without a single flaky failure. Add the test to the daily suite and tag it with the flow name so a failure points straight to login or checkout or navigation.
Running tests in continuous integration
Continuous integration runs UI tests after every merge or every release build. That timing catches a regression on the day that it appears. A developer can fix the regression while the change is still fresh in memory. A regression found weeks later takes longer to fix because the context is gone.
Emulators in continuous integration need a stable configuration. Choose a system image and a device profile that match your supported range. Record the configuration in the build script so every run uses the same setup. A changing emulator configuration can cause false failures that erode trust in the suite.
Handle flaky tests promptly. A flaky test that fails randomly teaches the team to ignore failures. That habit is dangerous because a real failure can hide among flaky failures. Quarantine a flaky test and fix it or remove it. A suite with no flaky tests earns trust and the team will act on every failure.
- Run UI tests after every merge or release build.
- Use a stable emulator image and device profile.
- Quarantine a flaky test until it is fixed.
- Act on every failure while the change is fresh.
Maintaining a suite as the app grows
A UI suite grows with the app and it needs maintenance like any code. Refactor test helpers when the interface changes. Share common steps such as login through helper functions. A helper that is used by many tests means that a change to login needs one edit rather than edits in dozens of tests.
Review test results regularly as a team. Look for tests that take too long and tests that fail often. A slow test may need a better wait strategy. A failing test may point to a real bug or to a brittle selector. Regular review keeps the suite fast and trustworthy over months of development.
Measure suite value by bugs caught and by time saved. A suite that catches a regression before release has paid for its maintenance. A suite that only consumes time without catching bugs needs a review of its coverage. Focus new tests on areas where manual testing recently missed a bug. That feedback loop keeps the suite relevant.
Code you can adapt
// Simple Espresso UI test for a login flow in your own app
@Test
fun loginShowsHomeScreen() {
onView(withId(R.id.emailInput))
.perform(typeText("[email protected]"), closeSoftKeyboard());
onView(withId(R.id.passwordInput))
.perform(typeText("test-password"), closeSoftKeyboard());
onView(withId(R.id.loginButton)).perform(click());
onView(withId(R.id.homeTitle)).check(matches(isDisplayed()));
}The snippet above is an original example written for this guide. It shows a focused UI test that checks a login flow end to end with clear assertions.
The test uses view identifiers rather than screen positions. That choice makes the test survive layout changes that move elements on screen. It also makes the test readable for a new team member. A readable test is easier to maintain when the login screen changes in a future release.
The final assertion checks that the home title is displayed. That assertion proves that login succeeded and navigation worked. A test without a final assertion only proves that the taps did not crash. Assertions turn a tap sequence into a real verification of user value.
How this topic connects to nearby work
Testable screens are easier to build when the architecture is chosen well as shown in the guide to MVVM vs MVI architecture patterns.
Test runs are part of total build time and the build side is optimised in the guide to optimize Gradle build speeds.
Failing tests produce logs that are easier to read with the filtering tricks in the guide to Logcat advanced filtering.
Putting it into practice
Screenshot testing complements tap based UI tests for visual regressions. A tap test proves that navigation works. A screenshot test proves that the screen looks right after navigation. Compare screenshots against a reference image with a tolerance for small rendering differences. A screenshot test that fails on every font change is too brittle. Set tolerance carefully and update references only after a deliberate design change.
Accessibility checks belong in UI automation as well. A test can check that key elements have content descriptions and that touch targets meet a minimum size. Those checks catch problems that sighted manual testing misses. Add accessibility assertions to core flow tests rather than creating a separate accessibility suite that runs rarely. Accessibility in every core test keeps the app usable for more users.
A final UI test check should run the suite on a slow device as well as on a fast emulator. A slow device reveals timing assumptions that a fast emulator hides. A test that passes on a fast emulator may fail on a slow device because an element appears later than expected. Condition based waits should handle that difference but only a slow device test proves it. Add one slow device run to the release checklist even when daily runs use emulators for speed. Record the slow device model and Android version with the result so a future failure on that device can be compared with the baseline run. A baseline for a slow device is as valuable as a baseline for a fast emulator today.
Common mistakes
A common mistake is to write one giant test for a whole user journey. A giant test is slow and its failures are hard to diagnose. Split journeys into smaller tests that each check one goal. Smaller tests run in parallel more easily and they point to the failing feature fast.
Another mistake is to rely on fixed sleeps. Fixed sleeps make tests slow on fast devices and flaky on slow devices. Use condition based waits that check for an element or a state. That habit alone removes a large share of flaky test failures.
A third mistake is to ignore flaky tests. A flaky test trains the team to ignore red builds. Quarantine flaky tests quickly and fix the root cause. A trustworthy suite is one where every failure deserves attention.
Frequently asked questions
How many UI tests should a small Android team write?
Start with core flows such as login and main navigation and key creation actions. A suite of ten stable tests beats a suite of a hundred flaky tests. Grow the suite as the team learns which areas break most often.
Should UI tests run on emulators or real devices?
Use emulators for fast feedback in continuous integration. Use real devices for final release checks and for hardware features such as camera and sensors. Both environments have value and they complement each other.
Why do my UI tests pass locally but fail in continuous integration?
Differences in emulator configuration or device speed or test data often cause that gap. Align the emulator image and the test data setup between local and integration runs. Condition based waits also reduce speed related failures.
Conclusion
Automated UI tests give Android teams fast and consistent feedback on core user flows. Stable selectors and condition based waits and isolated tests keep the suite trustworthy. Continuous integration catches regressions early while the change is fresh. Maintenance through shared helpers and flaky test discipline keeps the suite valuable as the app grows.
Your concrete next step is to automate one core flow in your own app today such as login and run it three times in a row. If it passes three times without a flaky failure then you have a stable foundation for a larger suite.
