Android Testing

Espresso Test Recorder in 2020

Alex Zhukovich 5 min read
Espresso Test Recorder in 2020
Table of Contents

Efficient UI testing series

Introduction

The "Espresso Test Recorder" was presented at Google I/O 16 together with Android Studio 2.2. It was great news for Android Developer and everyone who connected with the Android Development because we can now create UI tests in just a few clicks. However, even right now (January 2020) this tool is not so popular and we will try to understand why.

First of all, let's try to create a test case for one of the scenarios for the Standard Login screen.

Let's go back to the previous article when we discussed frameworks for Android UI testing and try to generate test case for similar scenario.

Espresso Test Recorder in Practice

Scenario:

  • Open SignInActivity;
  • Enter the "test" string into the email input field (id: R.id.email);
  • Press the "Sign In" button (id: R.id.signIn);
  • "An email address should be valid" message should be displayed (string const: R.string.error_email_should_be_valid).

Let's visualize a login screen of the application:

Test scenario

First of all, we should open the Espresso Test Recorder. We can find the "Record Espresso Test" submenu item in the "Run" menu item.

Open "Espresso Test Recorder"

The developing application will open on the device or emulator as well as the Espresso Test Recorder window.

Espresso Test Recorder

The next step is to start interaction with the connected device or emulator. Let's press the "LOGIN" button on device or emulator and you can see that the "Tap" action will be added to the "Espresso Test Recorder" window.

Espresso Test Recorder - Action

Let's finish the test case and do the following steps:

  • Tap on "Email address";
  • Enter the "test" text;
  • Hide the keyboard;
  • Tap on the "SIGN IN" button.

After that, the snackbar message will be displayed on the screen and we should press "Add Assertion" so that the screen of the device will be scanned and we will see the following screen of the "Espresso Test Recorder."

Espresso Test Recorder - Assertion

Afterwards, we should save the assertion and press the "OK" button. As a result, the test class will be created.

Espresso Test Recorder - Assert a View

However, we will have a situation in which only one test case will be added to the file. This case is easy as we don't need to wait for data from the file, database, or server, and everything works well. However, when you need to wait for data from any data source, you will have problems because your test will fail without waiting for data. However, we can use sleep or wait from UiAutomator framework, but I cannot recommend them. An additional problem is that the test case starts from the main screen of the application when recording the test scenario. Before the recording starts of the test case, we can change the main screen of the application in the AndroidManifest.xml file.

Generated code:

@LargeTest
@RunWith(AndroidJUnit4::class)
class SignInActivityTest {

    @Rule
    @JvmField
    var mActivityTestRule = ActivityTestRule(SignInActivity::class.java)

    @Test
    fun signInActivityTest() {
        val appCompatEditText = onView(
                allOf(withId(R.id.email),
                        childAtPosition(
                                allOf(withId(R.id.signInRoot),
                                        childAtPosition(
                                                withId(android.R.id.content),
                                                0)),
                                4),
                        isDisplayed()))
        appCompatEditText.perform(replaceText(" test"), closeSoftKeyboard())

        val appCompatButton = onView(
                allOf(withId(R.id.signIn), withText("Sign In"),
                        childAtPosition(
                                allOf(withId(R.id.signInRoot),
                                        childAtPosition(
                                                withId(android.R.id.content),
                                                0)),
                                6),
                        isDisplayed()))
        appCompatButton.perform(click())
    }

    private fun childAtPosition(
            parentMatcher: Matcher<View>, position: Int): Matcher<View> {

        return object : TypeSafeMatcher<View>() {
            override fun describeTo(description: Description) {
                description.appendText("Child at position $position in parent ")
                parentMatcher.describeTo(description)
            }

            public override fun matchesSafely(view: View): Boolean {
                val parent = view.parent
                return parent is ViewGroup && parentMatcher.matches(parent)
                        && view == parent.getChildAt(position)
            }
        }
    }
}

However, we can create the same test case in Espresso:

@RunWith(AndroidJUnit4::class)
class EspressoSignInTest {

    @Rule @JvmField
    val activityRule = ActivityTestRule<SignInActivity>(SignInActivity::class.java)

    @Test
    fun shouldDisplaySinInErrorWhenEmailIsIncorrect() {
        val incorrectEmail = "test"
        onView(withId(R.id.email))
                .perform(replaceText(incorrectEmail), closeSoftKeyboard())
        onView(withId(R.id.signIn))
                .perform(click())
        onView(withText(R.string.error_email_should_be_valid))
                .check(matches(isDisplayed()))
    }
}

As you can see, the Espresso Test Recorder cannot replace manually created test cases. So, let's analyze issues which this tool has right now:

  • One file has one test case, meaning that you will need a lot of files to cover basic scenarios;
  • No waiting mechanism supported; if the application waits for data from any data source, the recorded test will fail or we should manually use sleep or wait funntion from UiAutoator viewer as quick solution. However, generated test will fail without any changes;
  • Generated test code very detailed; this makes this test slow because the test case verifies many states and properties of View; usually, these checks can be skipped for the test case;
  • The "Espresso Test Recorder" generates code which is very complicated to maintain in the future;

While it cannot fully replace creating manual test cases, it can help at some point in a real project.

Note: I recommend to invest time in learning a test framework to create efficient and elegant test cases.

Espresso Test Recorder for developers and QAs

As you can see, the Espresso Test Recorder generates not very readable code and very often these tests execute longer when compared to manually created test cases. However, this tool can be helpful for developers in some cases.

Let's imagine that you don't have UI test cases. Unfortunately, this is a widespread case (during presentations about UI automation, I often ask the question: "How many of you write Android UI tests?" and the amount is always around 15-20%).

So, you want to do refactoring and you don't have a lot of UI tests. As a result, you can generate a few scenarios which can be broken after you finish refactoring. After refactoring you can be sure that the most important cases will be working well. However, the Espresso Test Recorder has many limitations and you cannot generate a test case for any case. We can use it for an error handling inside the application without waiting for data from data sources.

However, I recommend improve knowledge in test automation and creating efficient test cases which will work faster and are easy to maintain.

Resources


Mobile development with Alex

A blog about Android development & testing, Best Practices, Tips and Tricks

Share
More from Mobile development with Alex
Not all UI tests are the same
Android Testing

Not all UI tests are the same

The article explores different types of UI testing, such as end-to-end testing, UI testing with fake data, pixel perfection testing, and accessibility testing. The article also includes information on how to get started with UI testing in any project.
Alex Zhukovich 8 min read
How to test Android App Shortcuts
Android Testing

How to test Android App Shortcuts

The "App Shortcuts" feature allows users to access a specific part of the application from the device's home screen. Users can see all available shortcuts by long pressing on the icon of the applications. In this article, we will learn how to test app shortcuts in Android apps.
Alex Zhukovich 5 min read
How to group Android tests
Android Testing

How to group Android tests

Nowadays, mobile apps have many screens so that the projects can have many UI tests. When a project is large, we can have hundreds or thousands of UI tests, and running them locally can be time-consuming. In this article, we will explore different ways of grouping test cases.
Alex Zhukovich 17 min read

Great! You’ve successfully signed up.

Welcome back! You've successfully signed in.

You've successfully subscribed to Mobile development with Alex.

Success! Check your email for magic link to sign-in.

Success! Your billing info has been updated.

Your billing was not updated.