I’ve used Espresso whenever I needed reliable UI testing for native Android apps without adding unnecessary complexity. It integrates naturally with Android Studio and makes it easy to automate common user interactions like tapping buttons, entering text, and checking what’s displayed on the screen.
In this guide, I’ll explain how Espresso works, walk through its core features, show you how to write your first test, and share a few best practices I’ve found useful for building reliable Android UI tests.
What is the Espresso Testing Framework?
Espresso is a testing framework that helps developers write automation test cases for user interface (UI) testing. It has been developed by Google and aims to provide a simple yet powerful framework. Espresso is one of the popular Android App Testing Frameworks, that is widely used by QAs. It allows black-box testing, at the same time, allows QAs to test fragments and individual components during development cycles.
Espresso is highly robust. It allows developers to test both Android native views as well as hybrid web-views. Test cases using this framework can be written in Java or Kotlin, ensuring no new skill development is required to use it.
Using this framework, testers will be able to leverage a plethora of features. Synchronized test executions, intent validations, and capabilities to run recipes are some of its prominent features.
Read More: What is Espresso Testing? How does it work?
How Espresso Tests Work
When I write an Espresso test, I think about it the same way a user interacts with the app. Instead of focusing on the implementation, I start with what the user would do—tap a button, enter text, scroll through a list, or check what’s displayed on the screen. Espresso is designed around this workflow, making UI tests easier to read and maintain.
Most Espresso tests follow the same three-step pattern: find a UI element, perform an action, and check the result. Once you understand this flow, writing new tests becomes much more straightforward.
Step 1: Find the UI Element
Every Espresso test begins by locating the UI component you want to interact with. The onView() method works with matchers such as withId(), withText(), and isDisplayed() to identify the correct view.
// Locate a button and tap it onView(withId(R.id.button)) .perform(click());
Step 2: Perform an Action
After locating the element, you can interact with it using methods from ViewActions. Common actions include clicking buttons, entering text, scrolling, or swiping across the screen.
// Type text into an EditText field
onView(withId(R.id.editText))
.perform(typeText("Hello World"));Step 3: Check the Result
The final step is confirming that the UI changed as expected after the interaction. Espresso uses ViewAssertions together with matchers like withText() and isDisplayed() to compare the current UI state with the expected result.
// Check that the TextView displays "Success"
onView(withId(R.id.textView))
.check(matches(withText("Success")));Why Espresso Tests Are Reliable
A big reason developers choose Espresso is that it handles many of the common problems that make UI automation difficult. Instead of relying on manual delays or complicated test logic, Espresso is designed to keep tests readable and consistent.
- Automatic synchronization: Espresso waits for the UI thread to become idle before performing the next action or assertion. In most cases, this removes the need for manual delays like Thread.sleep(), making tests more stable and less prone to timing issues.
- Less code to maintain: Since synchronization is built in, Espresso tests require less setup and boilerplate code. The result is cleaner test scripts that are easier to read, update, and debug as the application changes.
- Built around user interactions: Espresso tests mirror the way people use an app. Whether you’re tapping a button, entering text, or scrolling through a list, the framework focuses on testing the UI from the user’s perspective rather than the implementation behind it.
Espresso’s API Components
Here are the four API components of Espresso that lay the foundation of Espresso Testing:
Espresso’s API Components
- Espresso
- ViewMatchers
- ViewActions
- ViewAssertions
1. Espresso
This is the starting point for all test cases. This component provides entry points or methods to start the interaction with the app’s view. Each app’s view has two components.
First is the part of the view that belongs to the app. Testers will be able to interact with it by using the onView() and onData() methods. The second part of the view consists of the components that are provided by the OS ( home screen button, back button, etc). Espresso also provides APIs to interact with non-app components. For example, the pressBack() method initiates going back.
2. ViewMatchers
Views are always in a hierarchy called the View Hierarchy. For the test cases to navigate the view hierarchy, ViewMatchers are used. Technically, they are a collection of objects, and they implement the Matcher interface. Testers will be able to pass one or more of these objects to the OnView() method provided by Espresso Component.
3. ViewActions
These components define the action that has to be performed on any given View. Espresso allows testers to send more than one ViewAction as a collection to the Interaction method. An example of a view action would be the click() method which helps a test script click on a given View’s UI component.
4. ViewAssertions
Assertions complete a test case. They are the components that check if the test has passed or failed. In Espresso Android, the ViewAssertions can be passed to the Check() method from the ViewInteraction package. Matches assertion is the most commonly used check which verifies the final state of the view with what is expected.
Espresso Cheat Sheet
When you’re writing Espresso tests, you don’t always remember every matcher, action, or assertion. That’s where a cheat sheet comes in handy. Instead of switching between your IDE and the documentation, you can quickly look up the syntax for common tasks and continue building your tests.
The Espresso cheat sheet brings together frequently used APIs, code patterns, and testing tips in one place, making it useful whether you’re learning the framework or working on a larger automation suite.
Source: Espresso
When to Use the Espresso Cheat Sheet
The cheat sheet is useful when you need to:
- Find common Espresso APIs quickly without searching through the official documentation.
- Write tests faster by referencing frequently used actions, matchers, and assertions.
- Handle common UI interactions like clicking buttons, typing text, scrolling, and swiping.
- Reduce flaky tests by understanding synchronization features such as IdlingResource.
- Keep test code consistent by following common Espresso patterns across your test suite.
- Debug failing tests by checking common assertions and troubleshooting approaches.
Common Examples
- Click a button
onView(withId(R.id.button)) .perform(click());
- Enter text
onView(withId(R.id.editText))
.perform(typeText("Hello World"));- Verify displayed text
onView(withId(R.id.textView))
.check(matches(withText("Success")));Keeping a cheat sheet nearby saves time when you’re writing or reviewing tests. Instead of remembering every API, you can focus on building reliable UI tests while using the reference whenever you need a quick reminder.
Setting Up an Espresso Test Environment
Before you can run Espresso tests, you need a project configured for instrumentation testing and an Android device or emulator to execute those tests. The setup is straightforward and only needs to be done once for each project.
1. Add Espresso Dependencies
Open your app-level build.gradle file and include the required testing libraries.
dependencies {
// Core Espresso library
androidTestImplementation 'androidx.test.espresso:espresso-core:3.5.1'
// JUnit
androidTestImplementation 'junit:junit:4.13.2'
// Optional: Test intents
androidTestImplementation 'androidx.test.espresso:espresso-intents:3.5.1'
// Optional: UI Automator
androidTestImplementation 'androidx.test.uiautomator:uiautomator:2.2.0'
// Optional: Idling Resources
androidTestImplementation 'androidx.test.espresso:espresso-idling-resource:3.5.1'
}Once you’ve added the dependencies, sync the project so Gradle downloads the required libraries.
2. Configure the Test Runner
In the same build.gradle file, specify the instrumentation test runner.
android {
defaultConfig {
testInstrumentationRunner "androidx.test.runner.AndroidJUnitRunner"
}
}This runner launches your Espresso tests on an Android device or emulator.
3. Prepare a Device or Emulator
Espresso tests must run on an Android environment.
If you’re using a physical device:
- Enable Developer Options.
- Turn on USB Debugging.
- Connect the device to Android Studio.
If you’re using an Android Emulator:
- Open Device Manager in Android Studio.
- Create or start a virtual device.
- Wait until the emulator is fully booted before running your tests.
4. Create the Test Directory
Instrumentation tests belong in the androidTest source set.
app/ └── src/ └── androidTest/ └── java/ └── com.example.app/ └── ExampleEspressoTest.java
Any Espresso test classes should be placed in this directory.
5. Run Your Tests
Once everything is configured, you can execute your tests in one of two ways.
From Android Studio
Right-click the test class or individual test method and select Run.
From the command line
./gradlew connectedAndroidTest
Gradle builds the app, installs it on the connected device or emulator, and runs all instrumentation tests.
Sample Test Case for Espresso Android
Based on the components discussed above, here is how one can write a test case with Espresso using:
1. Java
onView(withId(R.id.my_view),withText("Hello!"))
.perform(typeText("Hello"),click())
.check(matches(withText("Hello!")));2. Kotlin
onView(withId(R.id.my_view),withText("Hello!"))
.perform(typeText("Hello"),click())
.check(matches(withText("Hello!")))Code Explanation
Here’s what both the Java and Kotin test case above does.
- Firstly, it tries to find a view with a certain ID and a uniquely identifiable feature. In this case, the script is saying the text “Hello!” on the view is a unique feature.
- Next, the script performs two actions on that view. It first types “Hello!” on a text box that is present, and then it clicks on a button that exists.
- Finally, it calls the assertion matches() to check if the view shows “Hello!” once the click is performed. The result will be a successful test case if the view has the desired text on it. Otherwise, the test case fails.
Read More: How to test Toast Message using Espresso?
Run Espresso Tests on Real Devices
This Android Espresso tutorial strives to offer core information and starting points for action with the Espresso Testing Framework. The initial learning curve might seem a bit steep, which is true for any sort of automation testing. However, with time, it will pay off, and you will be saving a lot of time and money.
It is recommended for the SDETs and QA teams to run Espresso Tests on real devices and take real user conditions into account while testing. A cloud-based real device tool like BrowserStack App Automate provides access to all the latest and legacy real Android Devices such as Samsung Galaxy Devices, Google Pixel, One Plus, etc., to run your Automation tests and achieve accurate test results for better quality. Check out the entire List of Devices below.
Conclusion
Espresso is one of the easiest ways to automate UI testing for native Android apps. Its straightforward API, automatic synchronization, and tight integration with Android Studio help you build reliable tests without spending time managing waits or complex test logic.
As your application grows, testing on a single emulator is rarely enough. Running Espresso tests on real Android devices helps you catch device-specific issues across different manufacturers, screen sizes, and Android versions, giving you more confidence before every release.
