Introduction to User Interface (UI) Testing with Espresso

UI-Tests

In classic programming, the codebase is mainly covered with unit and integration tests. This should also be done in programming for Android. However, this article focuses on ensuring an error-free user interface (UI).

On Android, UI tests can be mapped natively using the Espresso framework. However, there are also other test frameworks such as Robotium, which can also be used to create UI tests for Android.

Espresso

Espresso is a framework from Google that was developed specifically for testing Android user interfaces. It was introduced at the Google Test Automation Conference in April 2013 and made available to developers in October of the same year. Espresso makes it possible to write native UI tests and thus directly access code from the development.

Setup

Since Espresso is a native framework, the setup is comparatively simple. The first step is to add the latest versions of the following dependencies to the application's build.gradle:

androidTestImplementation 'com.android.support.test.espresso:espresso-core:3.0.2'
androidTestImplementation 'com.android.support.test:runner:1.0.2'
androidTestImplementation 'com.android.support.test:rules:1.0.2'

Also, the test runner must be added to the defaultConfig section of build.gradle:

testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner"

Afterwards, the setup is complete and you can start writing the tests.

Tests with Espresso

In this example, we will test a small application that consists of two screens. The first screen contains two buttons and a TextView, the second screen contains a RecyclerView and a FloatingActionButton (FAB). Above the list there should be a TextView. Two fragments in an activity were used to implement the screens.
 The list was created using a RecyclerView.

If you click on the left button in the first screen, the counter in the TextView is incremented.

Figure 1: Clicking the right button opens the second screen

Figure 2: In the second screen, an element is to be added to the list when the FAB is clicked. An element of the list consists of a TextView and a checkbox.

The TextView should contain the element with number, i.e. "Item 0" for the first element, "Item 1" for the second element and so on. In addition, the number of elements that are selected and the number of the total elements should be displayed in the TextView above the list. This should be displayed as follows: "2/5 elements selected". After clicking on the "Back" button in the upper left corner, the view returns to the first screen.

Figure 3

UI tests are now defined for this application. The first step is to create a rule for the activity used.

public class MainActivityTestRule extends ActivityTestRule{

    public MainActivityTestRule(Class activityClass) {

        super(activityClass);
    }
}

The standard ActivityTestRule can also be used here. However, since something will be overwritten at this point later, a separate rule should be created for the MainActivity.

The first espresso test can now be written. For this you create a class in the "androidTest" folder, in which integration tests are searched for by default. Since no extremely large test class is needed, one class can be created for the first screen and one for the second screen. So that the rule can be used in both, you create the "BaseTest" class, from which both test classes can inherit. Then a new instance of the rule can be created:

@Rule
public MainActivityTestRule mActivityRule = new MainActivityTestRule<>(MainActivity.class);

In the next step, a test class can be created for the first screen. This inherits from "BaseTest". With the annotation @Test a method is now marked that represents a test. It is recommended to name the test methods in a meaningful way, so that it is immediately obvious what exactly is being tested. For UI tests, the following notation is recommended:

test_wasSollImTestPassieren_WasWirdErwartet()

This approach can lead to the names of the test methods becoming very long, but allows the developer to quickly see what is being tested in this method even without documentation.

The first test is to check if the UI was initialized with the correct values:

• The correct content is displayed in the text field
• Both buttons have the matching label

@Test
public void test_uiHasSetupCorrectly_AllViewsShouldBeVisibleAndHaveCorrectValues(){
    onView(withId(R.id.fragment_button_counter_text_view)).check(
                matches(withText("Number of Button Clicks: 0")));
    onView(withId(R.id.fragment_button_counter_button)).check(matches(withText("Count")));
    onView(withId(R.id.fragment_button_fragment_change_button)).check(
                matches(withText("Change Fragment")));
}

With onView() the view to be tested is selected. The id is the "android:id" specified in the XML layout file for a UI element. Then a matcher is expected via check(). In our case, only the string is compared in each case. Here it is better to use string resources instead of fixed strings. This has two advantages:

• One change immediately affects the test and application
• If the application is translated, you can run the tests regardless of the device language

For the test application, however, it is recommended to stay with fixed strings.

Now it is ensured that the screen has been built up properly. The next function of the first screen is to click on the left button and count up the counter in the text field. In addition to checking an element as in the previous test, clicking the button is also added here, i.e. an action:

@Test
public test_ButtonClickUpdatesCounter_CounterCountsUp(){
    onView(withId(R.id.first_screen_text_view)).check(matches(withText(“0 Klicks”)));
    onView(withId(R.id.first_screen_left_button)).perform(click());
    onView(withId(R.id.first_screen_text_view)).check(matches(withText(“1 Klicks”)));
}

First it checks if the initial value is correct, then the onView(withId()) selects the left button and perform() selects an action to be executed on the object. In our case, the action is click().

Subsequently, it should be checked whether the counter has been incremented. A distinction between singular and plural for one or more elements was omitted here. To ensure that this also works more than once, another test is added in which the button is clicked ten times:

@Test
public test_ButtonClickUpdatesCounter_CounterCountsUp(){
    onView(withId(R.id.first_screen_text_view)).check(
            matches(withText(“0 Klicks”)));
    for(int i = 0; i<10 ; i++{
                onView(withId(R.id.first_screen_left_button)).perform(click());
    }
    onView(withId(R.id.first_screen_text_view)).check(
            matches(withText(“10 Klicks”)));
}

The click() action is now executed ten times in a loop. Subsequently, the check is made whether it was counted correctly.

There is a second action in the first screen, whose correct execution is to be ensured by means of a UI test. Clicking on the right button should open the second screen.

To test whether the view has actually opened, you can check whether a layout element of the second screen is visible. Alternatively, you could also use the title of the toolbar or another unique feature of the view. In our case, the FAB was selected in the second screen:

@Test
public test_ButtonClickUpdatesCounter_CounterCountsUp(){
    onView(withId(R.id.first_screen_right_button)).perform(click());
    onView(withId(R.id.second_screen_floating_action_button)).check(matches(isDisplayed()));
}

After clicking on the button in the first screen, the FAB can be found via the layout ID and it is checked whether the button is displayed.

Now all functions of the first screen are covered. The tests for the second screen are created in the second test class. It is noticeable that all tests must first navigate to the second screen before they can be executed. Since this is true for all tests in this test class, the @Before annotation can be used here and executed before each test can be executed. Otherwise, a method would have to be called in each test that navigates to the second screen.

@Before
public void setUp(){
	onView(withId(R.id.first_screen_right_button)).perform(click());
}

Now you can start testing the second screen, the following should be tested:

• The UI has been built correctly in the basic state.

Clicking the FAB adds an item to the list, the TextView in the added item contains the correct text, and the TextView above the list has updated correctly.

• Selecting a checkbox updates the TextView above the list.
• Selecting a checkbox and then adding an item leaves the checkbox selected and the TextView above the list is updated correctly.
• Deselecting a checkbox and then adding an item leaves the checkbox deselected and the TextView above the list is updated correctly.

To check the UI in the basic state, only the content of the TextView above the list and the visibility of the FAB need to be checked here.

Now to the first test, which contains an element of a RecyclerView. The click on the FAB can be realized analogously to the clicks on the buttons in the first screen. To examine an element of a RecyclerView, you need your own ViewMatcher. With custom ViewMatchers, you can examine almost any element in Espresso. Often there are already implementations of ViewMatchers for UI elements. For the RecyclerView ViewMatcher was used.

Then, a method withRecyclerView() is introduced in the "BaseTest" class to call the watcher like the standard Espresso Matcher.

public static RecyclerViewMatcher withRecyclerView(final int recyclerViewId) {
    return new RecyclerViewMatcher(recyclerViewId);
}

Now the elements of the RecyclerView can be tested. Here you should get into the habit of scrolling to the index of the element before testing it. This is necessary because Espresso can only test an element that is displayed on the screen. To make the scrolling of the RecyclerView possible, we must now include the "espresso-contrib" repository. This contains additional possibilities UI elements, to match or interact with them. For our test we need these RecyclerViewActions:

@Test
public void test_clickFAB_itemIsAddedToListTextViewUpdated() {
    onView(withId(R.id.list_fragment_floating_action_button)).perform(click());
    onView(withId(R.id.list_fragment_recycler_view)).perform(RecyclerViewActions.scrollToPosition(0));
    onView(withRecyclerView(R.id.list_fragment_recycler_view).atPosition(0)).check(
            matches(hasDescendant(withText("Item 0"))));
    onView(withId(R.id.list_fragment_title_text_view)).check(matches(withText("0/1 items selected")));
}

After clicking the FAB, you scroll to the index of the list to be checked using the RecyclerViewAction scrollToPosition(index). While this is not strictly necessary here, since the first element of the List is normally always visible, but this way the step is not forgotten in other cases. Additionally one should consider that the device, with which one develops, is not necessarily the same device on which the tests must be executed.

Then, the matcher can be used to access the list element at location 0 and check whether one of its subviews contains the correct text. Since only one element with the corresponding text is provided here, this is sufficient.

The next step is to select a checkbox and then check whether the text above the list changes correctly:

@Test
public void test_addElementSelectElementCheckBox_shouldRefreshTextViewCorrectly() {
    onView(withId(R.id.list_fragment_floating_action_button)).perform(click());
    onView(withId(R.id.list_fragment_recycler_view)).perform(RecyclerViewActions.scrollToPosition(0));
    onView(withId(R.id.list_fragment_recycler_view)).perform(
            RecyclerViewActions.actionOnItemAtPosition(0, clickChildViewWithId(R.id.row_list_item_checkbox)));
    onView(withId(R.id.list_fragment_title_text_view)).check(matches(withText("1/1 items selected")));
}

A new feature is the click on the checkbox. Since the checkbox is located in a list element, you can use a RecyclerViewAction here again. With actionOnItemAtPosition an index and a ViewAction can be provided:

public class ChildClickViewAction {
    public static ViewAction clickChildViewWithId(final int resourceId) {
        return new ViewAction() {
            @Override
            public Matcher getConstraints() {
                return null;
            }

            @Override
            public String getDescription() {
                return "Click on a child view with specified id.";
            }

            @Override
            public void perform(UiController uiController, View view) {
                View v = view.findViewById(resourceId);
                v.performClick();
            }
        };
    }
}

In this case, the corresponding element within the given view is searched for via the ResourceId and this view is clicked on. After clicking on the checkbox, it is checked whether the TextView above the list has also been updated accordingly.

No new concepts are needed for the latest tests, so they are not explicitly listed here. However, both tests can be viewed via Github.

Finally, it should be checked whether the navigation via the "Back" button in the upper left corner works. Here we have to pay attention to a special feature: Unfortunately, Espresso cannot access the button with the id. At least not if it was created with setHomeAsUpEnabled(true). Instead, a description is used for this:

@Test
public void test_pressBackButton_shouldReturnToButtonFragment(){
    onView(withContentDescription(R.string.abc_action_bar_up_description)).perform(click());
    onView(withId(R.id.fragment_button_counter_text_view)).check(matches(isDisplayed()));
}

In order to click on the "Back" button, the description must first be determined. This has a fixed resource id, i.e. this test also works language-independently. The last step checks whether the TextView is displayed in the first screen.

Now the correct functioning of the app was almost completely ensured with UI tests. However, one special case should still be taken into account. So far, the tests would only run when the test device is unlocked. When the screen is off or the device is locked, all tests fail because the activity is not found. Therefore, the device should be unlocked and the screen should be turned on before the tests are executed. For this, the test device must not have a lock like a PIN.

For this we need to go back into our MainActivityTestRule class and implement the interface ActivityLifecycleCallback. This allows us to implement the onActivityLifecycleChanged() method.

@Override
public void onActivityLifecycleChanged(Activity activity, Stage stage) {
    if (stage == Stage.PRE_ON_CREATE) {
        activity.getWindow()
                .addFlags(WindowManager.LayoutParams.FLAG_SHOW_WHEN_LOCKED
                        | WindowManager.LayoutParams.FLAG_TURN_SCREEN_ON
                        | WindowManager.LayoutParams.FLAG_ALLOW_LOCK_WHILE_SCREEN_ON);
    }
}

Here you check if the activity is in PRE_ON_CREATE state, that is before it is created, and try to turn on the screen and unlock the device.

Additionally, the beforeActivityLaunched method must be overridden to set the listener. This way the tests will be executed even if the screen is turned off.

@Override
protected void beforeActivityLaunched() {
    super.beforeActivityLaunched();
    ActivityLifecycleMonitorRegistry.getInstance().addLifecycleCallback(this);
}

In conclusion, Espresso is a valuable tool in app development for Android, and its use in conjunction with other types of testing is highly recommended.

The entire application including all tests described here is available on GitHub.