Espresso Test Recorder – A quick How-to

Introduction

During Google I/O ‘16 we’ve heard an impressive list of new features to be included in the newest Android Studio 2.2. You can check this cool video here with all the details: What’s new in Android development tools – Google I/O 2016

Android Studio 2.2 introduces many new tools that make developer’s life definitely easier. Layout Editor and Constraint Layout, Firebase plugin integration, Jack compiler, and much more. One of these novelties is also Espresso Test Recorder. This new feature lets us record user interactions on device or emulator, and then creates fully working Espresso tests code. Then you can run this tests on your device, your Continuous Integration or in Firebase Test Lab. Let’s try this!

What is Espresso Test Recorder?

Espresso is a framework for UI testing. It’s the part of Android Testing Support Library for simulating user interactions in the application. To create the test, normally you’ll need to write code on your own. Thanks to Espresso Test Recorder, part of this job can be done automatically.

To run this new feature you need:

• Android Studio 2.2 Preview 3

Also, you need to add Gradle dependencies for Espresso:

Espresso in practice

To start with test recording you need to open existing project. In my case, it was an application for making notes, which has one simple screen containing two AutoCompleteTextViews, Button and RecyclerView with notes. In the opened project select Run -> Record Espresso Test

Then you’ll need to select target device for running the app. You can choose the physical device or emulator. Next, you’ll see “Record Your Test” window and the app will run on your device.

In this window, you’ll see every interaction you’ve made on the screen, every taping or text typing. We haven’t done anything yet, so all we see is the message “No events recorded yet”. If I would make some interaction, e.g. I would type some text and tap on the button in the app, I see new events:

These events tell me that I typed texts “Note title” and “Note message” into two TextViews and then tapped on “Add note” button.

If we want to check if we ‘ve added new note correctly, we can make an assertion. You could tap on “Add Assertion” button that creates a clickable screenshot of your current screen. You can select an element and add an assertion to it. For example, I can select some TextView and Espresso Test Recorder tool will suggest me to assert that “id/text_note_title text is Note title”

For now, there’re no many automatic assertions available. You can only choose:

• for View: exists/does not exist
• for TextView and subclasses: text is/exists/does not exists

If you want some additional assertions, you’ll need to write it in the code on your own.

After making some events, we can finish test by tapping on “Complete Recording”. In the next window, we’ll be asked to choose the name for our test (there’s restriction that one UI test is created in one class). Then if we don’t have Espresso dependencies, we’ll be asked to add them:

If we have, Android Studio will generate test class for us:

As you can see, Android Studio also generated ViewMatcher for finding view at some position, in this case, used for finding the first note in our RecyclerView. It’s very time-saving.

Limitations

Because Espresso Test Recorder is still in experimental phase, it has some issues too. The most crucial in my opinion are:

• limited assertions number – in most cases, we’re able to assert only that some UI element exists or doesn’t exist (the only exception is TextView with additional assertion “text is”), so we need to write other assertions in the code
• no support for IdlingResources, so if you have some animation on view or some long-running operation, you’ll need to handle it by yourself, because Espresso Test Recorder doesn’t know how long should wait and the test will fail because of unknown view
• no support for UI interactions that are outside of your code, so Facebook, Twitter, Google+ and other external sources of UI like WebViews, Google Play dialogs, etc. need to be handled on your own

Summary

Espresso Test Recording is great for someone who hasn’t ever tried UI testing. You don’t need to know how to use Espresso for writing simple tests. You can also check how they should look like (the proper annotations, the naming convention). And in some cases, it’s definitely quicker to record the test rather than write it, mainly if we have lists with many items.

However, Espresso Test Recording has still many limitations that I’ve described above. And it doesn’t save so much time, especially when we need to type a lot of text (which takes really a lot of time in test recording mode).

Despite all these, I encourage you to try this new feature and see if this is helpful for you.

Related posts