@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 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:
In some cases, it may be necessary to close the keyboard. Following example shows usage of closeSoftKeyboard() method.
pressBackUnconditionally() does not throw exception when Espresso navigates outside of application or process under test. However, pressBack() method throws exception.
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.
If there is no ActionBar there will be exception thrown.
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.
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.
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;
EditText testing may require special controls, in this case we have following Matchers;
TextView testing may require special controls, in this case we have following Matchers;
Spinner testing may require special controls, in this case we have following Matchers;
WebView testing may require special controls, in this case we have following Matchers;
Accessibility testing may require special controls, in this case we have following Matchers;
withContentDescription (Matcher<? extends CharSequence> charSequenceMatcher)
Lets use multiple Matchers in Espresso;
Next article Part 2 - Body.