Espresso Android UI Automation: A Complete Tutorial [2026]

What Is Espresso in Android?

Espresso is a UI testing framework, developed by Google, used in Android development to write automated tests that interact with views and verify screen behavior.

It is part of the AndroidX testing libraries and is typically used within Android Studio alongside Java or Kotlin test script.

Core Features:

• Direct Access to Android UI Components: You can run Espresso tests inside the app process, which lets you interact with Buttons, TextViews, RecyclerViews, and other Android views without adding custom synchronization code.
• Built-In UI Synchronization: Espresso waits for the main thread and background tasks to become idle before performing actions or checks, so you do not need to add manual delays in most cases.
• Works Within Android Studio: You can write, run, and debug UI tests using the same environment you already use for Android development, including Gradle and standard test runners.
• Action-and-Assertion Structure: Espresso separates user actions from UI checks, which helps you keep test cases readable and easier to maintain.
• Supports Java and Kotlin: You can write Espresso tests in either language, matching the language used in your Android app.

For more details, check out this Espresso tutorial.

What Are the API Components of Espresso?

Component APIs of Espresso include onView() and onData() for starting UI interactions and global actions. ViewMatchers find UI elements, ViewActions perform user actions, and ViewAssertions verify view states after interactions.

• Espresso: You can use this as the entry point for interacting with the UI. It provides methods such as onView() and onData() to begin view interactions, along with APIs that are not tied to a specific view, such as pressBack().
• ViewMatchers: You can use these to locate views within the current view hierarchy. ViewMatchers implement the Matcher<? super View> interface and are passed to onView() to identify UI elements based on properties like ID, text, or visibility.
• ViewActions: You can use these to define actions performed on a matched view. ViewAction objects are passed to ViewInteraction.perform() and include operations such as click(), typeText(), and scrollTo().
• ViewAssertions: You can use these to verify the state of a view after an action. ViewAssertion objects are passed to ViewInteraction.check(). In most cases, you can use the matches() assertion with a ViewMatcher to confirm that the selected view meets the expected condition.

Advanced Techniques for Espresso Test Automation

Other than the core API components, Espresso also supports various advanced features to make your Android testing more reliable and maintainable.

Let’s have a look at a few of them.

• Idling Resources: Espresso runs test actions synchronously by default, but this behavior applies only to operations tracked by Espresso itself.

For asynchronous work such as network requests or background data loading, Espresso needs to be informed when the app is busy and when it can safely continue executing test steps. Idling Resources act as a signaling mechanism that tells Espresso when an asynchronous operation starts and finishes.

Example:

IdlingResource idlingResource = new CountingIdlingResource("resource_name");

// register the idling resource before the test
@Before
public void registerIdlingResource() {
    IdlingRegistry.getInstance().register(idlingResource);
}

@After
public void unregisterIdlingResource() {
    if (idlingResource != null) {
        IdlingRegistry.getInstance().unregister(idlingResource);
    }
}

• Espresso Intents: Intents are used to intercept, mock, and validate outgoing Android intents during test execution. It allows verification that the correct intent is triggered or enables stubbing a response instead of launching the actual external activity or system component.

This approach is useful when the app interacts with other apps or software services, allowing tests to focus on internal app behavior.

Example:

Intents.init();
intended(hasComponent(NewActivity.class.getName()));
Intents.release();

• Multiprocess Mechanism in Espresso: Multiprocess supports testing applications that run across multiple processes. This is relevant for apps that rely on services or content providers outside the main process.

With multiprocess support enabled, Espresso can coordinate interactions across processes while maintaining synchronization and test stability.

Example:

Log.d(TAG, "Checking main process name...");
onView(withId(R.id.textNamedProcess)).check(matches(withText("com.example.android.testing.espresso.multiprocesssample")));
Log.d(TAG, "Starting activity in a secondary process...");
onView(withId(R.id.startActivityBtn)).perform(click());

• Espresso-Web: Many Android apps include WebViews, especially in hybrid app scenarios. Espresso-Web provides APIs to interact with web elements rendered inside a WebView.

It allows actions such as locating elements and performing user interactions. Espresso-Web relies on WebDriver Atoms to interact with WebView content.

Espresso-Web enables basic interaction and validation but is not a replacement for full browser automation. For testing web applications in depth, WebDriver-based frameworks are more suitable.

Example:

onWebView()
// find element with id specified
.withElement(findElement(Locator.ID, "text_input"))
// Clear previous input
.perform(clearElement())

Troubleshooting Espresso Issues and Solutions

When working with Espresso, you may run into setup, sync, or test execution issues, so understanding common issues and their solutions helps keep Android UI tests stable and reliable.

WebView Not Detected by Espresso

• Issue: Espresso fails with NoMatchingViewException or NoActivityResumedException when a WebView is opened, especially via SDKs or external intents.
• Solution: Ensure the WebView is part of the current activity’s view hierarchy. If the WebView is launched via an external SDK or browser intent, Espresso-Web cannot interact with it. In such cases, UI Automator or mocking the SDK flow is typically required.

Espresso Does Not Wait for the WebView to Load

• Issue: Tests fail because Espresso attempts to interact with web elements before the WebView finishes loading content.
• Solution: Enable JavaScript in the WebView and use onWebView() only after the page load completes. For complex cases, register a custom Idling Resource tied to WebView loading state.

Cannot Interact With WebView Elements Due to JavaScript Restrictions

• Issue: Errors occur when Espresso-Web attempts to evaluate JavaScript, often caused by Content Security Policy or restricted JS execution.
• Solution: Verify that JavaScript is enabled in the WebView and that the page allows script execution. If the content blocks script evaluation, Espresso-Web cannot interact with it.

No Way to Assert That a Web Element Does Not Exist

• Issue: Espresso-Web lacks a direct equivalent to doesNotExist() for web elements.
• Solution: Wrap element lookups in try/catch blocks or use conditional logic to infer absence. Some teams combine Espresso-Web with UIAutomator for negative checks.

Dependency or Version Conflicts Break Espresso-Web

• Issue: Runtime errors such as NoSuchMethodError appear when using Espresso-Web alongside mismatched AndroidX or test libraries.
• Solution: Align all AndroidX Test, Espresso Core, and Espresso Web versions in build.gradle. Mixing legacy support libraries with AndroidX often causes failures.

Best Practices for Writing Maintainable Espresso Tests

When working with Espresso, test failures or inconsistent behavior can occur for several reasons. The following tips help isolate and resolve common issues:

• Verify Element IDs: Use Android Studio’s Layout Inspector or UI Automator Viewer to confirm resource IDs and view properties before writing matchers.
• Handle Asynchronous Operations: Avoid Thread.sleep(). Use Idling Resources to signal when background tasks such as network calls or database operations are complete.
• Register and Unregister Idling Resources: Always unregister Idling Resources after each test to prevent interference between test runs and shared idle states.
• Check Gradle Dependencies: Inconsistent or conflicting AndroidX and testing library versions often cause runtime failures. Keep dependency versions aligned in build.gradle.
• Run Tests in Isolation: Shared state across tests can lead to flaky behavior. Use ActivityScenarioRule or setup and teardown hooks to reset app state for every test.
• Use Logs and Screenshots for Debugging: Logcat output and failure screenshots provide context that helps identify why a test failed.
• Test Across Devices and API Levels: Some issues only appear on specific devices or Android versions. Running tests in multiple environments helps uncover these cases.

Espresso vs Appium: What Are the Differences?

Espresso is built for Android apps and runs inside the app for fast, reliable UI tests. Appium supports Android and iOS, works externally, and is better for cross-platform and end-to-end testing.

Conclusion

Espresso is a commonly used framework for automating UI tests in Android applications. Its tight integration with the Android toolchain and built-in synchronization make it suitable for validating UI behavior during development.

While emulators are useful for faster feedback, running tests on real devices is important for covering variations in hardware, OS versions, and system behavior. Real device platforms, such as TestMu AI, help run the same tests across multiple devices without maintaining physical infrastructure.

By following best practices and using Espresso’s advanced features where appropriate, teams can build UI tests that are easier to maintain and more consistent over time.

Citations