Setting Up a Virtual or Physical Device for Test Automation

These animation properties are available from the Settings ➤ System ➤ Developer option, inside the Drawing section, as shown in Figure 10-1.

And of course, we want all animations to be disabled automatically. This is achievable in two ways. We can execute the following shell commands before the test runs or when the device starts.

The second option is to execute the same commands, but using a UiDevice instance before the test runs.

In this example, we used the @BeforeClass annotation to execute it once for the whole test class.

The second device property that can bring flakiness is the Touch and Hold Delay. You can find it in the System ➤ Accessibility section, as shown in Figure 10-2.

The second option is run from inside the @BeforeClass method , as follows.

By the way, the default Short value is set to 500 milliseconds, Medium is set to 1000 milliseconds, and Long is set to 1500 milliseconds.

Let’s now discuss the final device property that can cause flakiness in our tests—the virtual keyboard appearance. At first look, the virtual keyboard seems not related at all to test flakiness but there is one thing we have to keep in mind—Espresso for Android operates only in our application under the test context and it is not allowed to interact with any third-party applications.

You can also execute the same command from inside the test, as follows.

After combining all the mentioned commands, here is what we get.

It does not matter which approach you use to set test devices in a test friendly state; they will definitely make your automated tests more reliable and less flaky.

Using the Espresso Test Recorder Tool

The Espresso authors were probably inspired by the Selenium IDE test recorder and decided to add this same capability into Espresso as well. The Espresso Test Recorder tool allows inexperienced users to create Espresso UI tests with less effort. It became available and stable in Android Studio version 2.3.

The Test Recorder tool is integrated into Android Studio IDE and available from the Run ➤ Record Espresso Test menu, as shown in Figure 10-3.

Before starting, you should have a test device connected or a virtual device created in advance. After recording is triggered, you are asked to select a target device. After the application is built, it will be deployed to the target device and will run in debug mode. See Figure 10-4.

While recording is ongoing, application interactions will be tracked and shown inside recorder view. Figure 10-5 demonstrates adding a new TO-DO flow in the sample application.

The Add Assertion button allows you to add an assertion of the following types (see Figure 10-6):

• Text is—Equivalent to check(matches(withText()))

• Exists—Equivalent to check(matches(isDisplayed()))

• Does not exist—Equivalent to check(doesNotExist())

After you are done with the recording and you click the OK button, you will be asked to provide the name of the test class and select the test class language (Java or Kotlin). See Figure 10-7.

You can’t save a recorded test in a test class that already exists. If you try to do this, the error in Figure 10-8 will be shown.

By default, recorded tests are stored inside the tasks package , which is automatically created inside the application’s package. See Figure 10-9.

The Espresso Test Recorder can be tweaked from inside Android Studio preferences. You can observe that with the default depth values (Max UI depth = 3, ScrollView detection = 5, and Assertion depth = 3), the test recorder and the application are quite slow. If you lowering them to 1 or 2, they become much more responsive. See Figure 10-10.

Next, you can see how clicking on the Add TO-DO floating action button is recorded with the default depth values.

Here is an example of the same action, but with the Max UI depth set to 1.

You can observe and compare how the add new TO-DO test code looks when recording it with the default depth values in the chapter10.testrecorder.AddTodoEspressoTestRecorder.kt class and with the depth values set to 1 in the chapter10.testrecorder.AddTodoEspressoTestRecorderLowerDepth.kt class.

Running Espresso Tests in the Firebase Test Lab from Android Studio

It is widely known that the Android platform, by its nature, has significant device fragmentation. To deal with this, you may have a wide range of mobile devices based on the usage statistics. But this is quite costly, taking into account the fact that you have to maintain it. Even if this is a must-have in manual testing, in test automation we tend to use Android emulators, custom device labs, or third-party services. Third-party services did provide such a possibility for mobile developers but they were not standardized and were costly. Then Google decided to bring its own device-testing solution into the Android ecosystem. It’s called the Firebase Test Lab. It allows developers to run automated tests on real devices or emulators without the need to maintain them.

Let’s look at how to start using Firebase and what benefits it brings. First, starting from https://firebase.google.com/ , you should navigate to the Firebase console and log in with your Google account (see Figure 10-11).

There you will notice that you will already have a couple of sample projects to play with and the possibility to add your own by clicking on Add Project. See Figure 10-12.

After clicking Add Project, you will be asked to provide the project name and select other parameters related to the service location. When the project name is provided, the project will automatically receive its project ID, which is a unique identifier for your Firebase project. See Figure 10-13.

After you are done with it, you will land on the Project Overview screen. From there, you can navigate to the Test Lab, as shown in Figure 10-14.

It is now all set and ready to be used by our automated tests. Since we want to run them via Android Studio, we have to set up the proper test configuration from there. To do this, we open the Run ➤ Edit Configurations… menu, select Android Instrumentation Tests, and add a new one by clicking on the + button, as shown in Figure 10-15.

In the Deployment Target options, we should set the Firebase Test Lab Device Matrix option as a target and then sign in with the same Google account into the Firebase, as shown in Figure 10-16.

After that you can select your project and configure the device matrix, as shown in Figure 10-17.

Figure 10-18 shows how the device matrix dialog looks.

It’s worth mentioning that, for our sample project, we used the Spark pricing plan, which is free and has its limitations. You get 10 tests per day on virtual devices and five tests per day on real devices.

When all is ready, we can select and run the test using the Firebase test configuration, as shown in Figure 10-19.

When the test execution is finished, we can return to the Firebase Test Lab console and observe the test results from the last run, as shown in Figure 10-20.

After clicking on the specific test execution, you will land at the detail test run description with the possibility to preview device logs, recorded video, and device performance during the test run (see Figure 10-21).