Photo: Source

Espresso Recipes for Android - Part 1 - Hearth

In this tutorial series, you will find details of Espresso API in a simple manner. As a detail-oriented person, I tried to feed this tutorial series with deep knowledge.

@Espresso 2.1 Components

Espresso testing API provides support for locating UI elements and interacting with them. It prevents direct access to activities and views of the application to avoid flaky tests. We can operate on views with ViewAction and ViewAssertion classes. Espresso API including following components.

@Espresso

Espresso class is core of Espresso API. It provide interactions with view components through onView() and onData() methods. Its also have top-level user actions like backPress(). Lets start with top level actions.

Espresso Top Level Actions:
Espresso.closeSoftKeyboard()
In some cases, it may be necessary to close the keyboard. Following example shows usage of closeSoftKeyboard() method.

Instrumentation for above code

Espresso.pressBack() & Espresso.pressBackUnconditionally()
Its possible to use physical back press button with two different methods.

Instrumentation for above code

pressBackUnconditionally() does not throw exception when Espresso navigates outside of application or process under test. However, pressBack() method throws exception.

Espresso.openActionBarOverflowOrOptionsMenu(Context context)
If we try to use view components which are not displayed in screen, Espresso API throws an exception. This method helps overflow menu items to display on screen in order to test.

Instrumentation for openActionBarOverflowOrOptionsMenu()

If there is no ActionBar there will be exception thrown.

Espresso Utils:
Espresso.setFailureHandler(FailureHandler failureHandler)

If there is no ActionBar set in Activity, there will be exception thrown. setFailureHandler() method of Espresso API can be used to handle this Exception.

Espresso View Interactions:
Espresso.onView(Matcher<View> viewMatcher)
Creates ViewInteraction for a given view. View searched with onView() should be part of view hierarchy.

If the target view is inside an AdapterView - such as ListView, GridView, or Spinner - the onView() method might not work. In these cases, you should use onData() instead.

@ViewMatchers

Lets remember anatomy of UI test. In order to test UI components we should first find the view. We are going to use Matchers for this purpose.

Before starting ViewMatchers, it will be good to learn about their root org.hamcrest.Matchers. Hamcrest is a framework that assists writing software tests in the Java programming language. Hamcrest framework has Matchers class. We are using Matchers basically to check that conditions Match or not. To understand more detaily please follow this slide.

Further information about Matchers can be found on official documentations. Following ones are most usefuls.

allOf(), any(), anyOf(), anything(), arrayWithSize(), contains(), empty(), endWith(), hasItem(), hasValue(), instanceOf(), is(), not(), theInstance().

We are especially going to use allOf(), anyOf(), is() and not().

Espresso.onView method takes ViewMatchers as argument. This means first step with Espresso API will be identifying UI components. We are going to use ViewMatchers widely. Lets take a look at them!

In order the test UI first thing is finding view. Following ViewMatchers can be used for this purpose;

Often the desired view has a unique R.id and a simple withId() matcher will narrow down the view search. However this is not case always. For example ActionBar overflow menu items should be found by withText() matcher.

If there is duplicate texts, we should use hierarchy methods to narrow down the search. Least descriptive matcher that finds the one view you’re looking for. For example, if a view is uniquely identifiable by its text, you need not specify that the view is also assignable from TextView. For a lot of views the R.id of the view should be sufficient.

Some views dont have id, for example ActionBar menu items or simple TextViews. In those cases we can use following methods to identfy UI elements;
withText(Matcher<String> stringMatcher)
withText(String text)
withText(int resourceId)

EditText testing may require special controls, in this case we have following Matchers;
hasErrorText(String expectedError)
hasErrorText(Matcher<String> stringMatcher)
hasImeAction(int imeAction)
hasImeAction(Matcher<Integer> imeActionMatcher)
withHint(Matcher<String> stringMatcher)
withHint(int resourceId)

TextView testing may require special controls, in this case we have following Matchers;

hasLinks()
hasTextColor(int colorResId)

Spinner testing may require special controls, in this case we have following Matchers;

withSpinnerText(int resourceId)
withSpinnerText(String text) withSpinnerText(Matcher <String> stringMatcher)

WebView testing may require special controls, in this case we have following Matchers;
isJavascriptEnabled()

Accessibility testing may require special controls, in this case we have following Matchers;
hasContentDescription()
withContentDescription(String text)
withContentDescription(int resourceId)
withContentDescription (Matcher<? extends CharSequence> charSequenceMatcher)

Lets use multiple Matchers in Espresso;

@After

Next article Part 2 - Body.

References
https://developer.android.com/training/testing/espresso/basics.html
https://www.slideshare.net/shaiyallin/hamcrest-matchers
https://www.youtube.com/watch?v=uCtzH0Rz5XU