A Deep Dive into Android Espresso

A step by step guide on how to write automation tests with Espresso framework

Photo by Ankush Minda on Unsplash

To be honest, I’ve never been such a big fan of automation testing. In every company I’ve worked for in the last 15 years, implementation of the automation testing process has always failed. However, things have changed dramatically…

In the past, development and QA were two isolated processes running in sequential phases. With the advent of Built-in Quality practices and Agile, DevOps and Shift Left approaches, this scenario has completely changed.

Today, development is closely tied to testing. On one hand, developers are being incorporated into the testing cycle earlier than ever before. On the other hand, QA testers have to adapt quickly and learn development skills.

In line with these new practices and approaches, today we have an extensive ecosystem of automation tools, CI systems and testing frameworks. Google’s Espresso testing framework is one of them.

What is the Espresso Framework?

The Espresso testing framework provides a set of APIs to build UI tests to test user flows within an app. These APIs let you write automated UI tests that are concise and that run reliably. Espresso is well-suited for writing white box-style automated tests, where the test code utilizes implementation code details from the app under test.

The main components of Espresso:

• Espresso : Entry point to interactions with views (via onView() and onData()). Also exposes APIs that are not necessarily tied to any view, such as pressBack().
• ViewMatchers: allows you to find a view in the current view hierarchy.
• ViewActions: allows you to perform actions on the views.
• ViewAssertions: allows you to assert the view state.

Espresso vs. Appium

Below are the key differences between the two popular test automation frameworks for mobile app testing: Appium and Espresso.

Espresso setup instructions

Add Espresso dependencies

In your app’s top-level build.gradle file, you need to specify these libraries as dependencies:

Set the instrumentation runner

testInstrumentationRunner "androidx.test.runner.AndroidJUnitRunner"

Location of Espresso Tests

In your Android Studio project, you must store the source files for espresso tests at module-name/src/androidTest/java/. This directory already exists when you create a new project that contains an example instrumented test.

JUnit 5 support

Currently, there is no support for JUnit5. :(

Espresso Test Recorder

The Espresso Test Recorder tool lets you create UI tests for your app without writing test code. By recording a test scenario, you can record your interactions with a device and add assertions to verify UI elements in particular snapshots of your app. Espresso Test Recorder then takes the saved recording and automatically generates a corresponding UI test that you can run to test your app

To start recording a test with Espresso Test Recorder:

1. Click Run > Record Espresso Test.
2. In the Select Deployment Target window, choose the device on which you want to record the test. Click OK.
3. Espresso Test Recorder triggers a build of your project, and the app must install and launch before Espresso Test Recorder allows you to interact with it. The Record Your Test window appears after the app launches. Interact with your device to start logging events such as “tap” and “type” actions.
4. To save a recording, click OK.

Let’s write some Espresso tests!

In our sample app (see below), we would like to validate the LoginActivity screen:

Let’s write a simple example on how to validate the scenario when a user enters valid/invalid credentials:

Here, we use the ActivityScenarioRule, which launches a given activity before the test starts and closes after the test. You can access the ActivityScenario via the getScenario() method, which allows you to run an action on the current activity, launch an activity and more. This rule is an upgraded version of ActivityTestRule. The previous version will be deprecated and eventually be removed from the library in the future.

When the user enters valid credentials, we validate that the login button is enabled, and the welcome string contains the user name entered. However, when the user enters invalid credentials, we validate that the login button is disabled, and an error popup is displayed with the correct error message.

Now, let’s write a more advanced example: how to validate that clicking on the login button is sending the correct Intent:

Here, we use the IntentsActivityRule, which initializes Espresso-Intents before each test and releases Espresso-Intents after each test run.

When the user enters valid credentials and clicks the login button, we validate that a new Intent was sent with the MainActivity component and with an extra named “displayName” containing the user name entered.

What if we wanted to do some setup in our Activity before launching it?

With the current version of ActivityScenarioRule we aren’t able to do this.ActivityScenarioRule launches the Activity before we can get to our test method where we would actually like to do the setup, e.g. set some Intent extras.

For this, we need to use ActivityScenario directly and remember to clean up afterwards, e.g. in an @After annotated method or with the help of a try-with-resources block. See the example below:

Here, we are launching the MainActivity only after we setup the Intent with a long display name.

That’s all! I hope you liked this article. Happy testing!

Extra articles and resources to look at:

1. Source code for the sample app in this article is available at: https://github.com/oaviad/espressoClub
2. Espresso Cheat Sheet
3. Espresso Basics
4. Espresso Test Recorder
5. Double Espresso Anyone? ☕️