UI Automator: Black-Box UI Testing for Android
Think of UI Automator as a robot that tests your app by looking at the screen, not your code. It's for end-to-end tests that cross app boundaries, like interacting with the system Settings. The footgun: tests are powerful but can be slow and brittle.
Why it exists
Apps don't live in a vacuum; they interact with the Android OS and other apps. Developers needed a way to test user flows that span multiple applications or system UI, simulating how a real user navigates their device from end to end.
The mental model
UI Automator is like a robot arm with a camera pointed at the device's screen. It has no knowledge of your app's internal code or architecture. It operates purely from the "outside," finding UI components based on what's visible (text, content description, ID) and performing actions like tapping, swiping, or typing. It tests the final, rendered output.
How it works
UI Automator runs as an instrumented test on a physical device or emulator. It leverages Android's accessibility services to inspect the current screen's view hierarchy. Your test code uses the UI Automator API to query this hierarchy for a specific object (e.g., a button with the text "Login"). Once found, you can command it to perform an action, like click(), and then assert that the resulting UI state is correct.
When to use it
Use UI Automator for true end-to-end (E2E) system tests. Its key strength is cross-app testing. For example, testing a flow where your app launches the camera to take a picture, or opens the Settings app to toggle Wi-Fi, and then verifies the result back in your app. It's for validating critical user journeys from start to finish.
When not to use it
Avoid it for tests that can be done within your own app's process. For single-app UI testing, Espresso is generally faster and more reliable because it runs in the same process as your app and can synchronize with UI thread operations. Using UI Automator for simple component tests is overkill and leads to slow, flaky test suites.
One canonical example
A test could verify a "Share" feature. The test would launch the app, navigate to a piece of content, tap the "Share" button, and then verify that the Android system's share sheet appears. The test could even select an app from the share sheet and assert that the correct content was passed to it. This flow is impossible to test with a framework confined to a single app.
Interview question
Which testing scenario is best suited for UI Automator?
- a.Performing rapid feedback tests on individual screen elements during active development.
- b.Ensuring that user input in a form is correctly validated before submission.
- c.Automating a user journey that starts in your app, opens the system camera, and returns to your app.Correct
- d.Testing the visual appearance and responsiveness of a new UI component within your app.
Why? this is the answer
UI Automator's primary strength is testing user flows that span multiple applications or interact with system UI, such as launching the camera. For single-app UI component validation or rapid feedback, frameworks like Espresso are generally preferred.
Just read this? Test yourself on what you have been reading.
Read the original → developer.android.com
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on android — each one lists the topics its interview covers.
See open roles