Adapting Espresso Swipe Actions

As you may guess, GeneralLocation.BOTTOM_CENTER and GeneralLocation.TOP_CENTER represent the from and to coordinates inside the view we would like to swipe. The full positions list, which can be used as from and to coordinates, are TOP_LEFT, TOP_CENTER, TOP_RIGHT, CENTER_LEFT, CENTER, CENTER_RIGHT, BOTTOM_LEFT, and BOTTOM_CENTER, BOTTOM_RIGHT.

Swipe.FAST represents the length of time a “fast” swipe should last, in milliseconds. For now, Swipe has FAST (100 milliseconds) and SLOW (1500 milliseconds) swipe speeds.

The Press.FINGER returns a touch target with the size 16x16 mm. Other press options are PINPOINT 1x1 mm and THUMB 25x25 mm press areas.

The -EDGE_FUZZ_FACTOR value defines the distance from the edge to the swipe action’s starting point in terms of the view’s length. This is helpful when swiping from the exact edge can lead to undesired behavior—for example, opening the navigation drawer.

The other three swipe actions happen in a similar way, with the difference only in the from and to coordinates.

There may be cases when these four swipe actions are not enough. You may need swiping left or right slowly or swiping up or down from the middle of the screen. In such cases, you can create your own custom swipe action.

To implement our own action, we will follow the approach of how Espresso swipe actions like swipeDown() are implemented. First, we add our own CustomSwipe type and call it CUSTOM. This enum class should implement the Espresso Swiper interface like Swipe enum does, where the FAST and SLOW swiping types are declared.

In our implementation, we can control the swipe duration by setting it in the setSwipeDuration() method, which modifies the swipeCustomDuration static variable. We also have to paste the interpolate() and sendLinearSwipe() methods from the Espresso Swipe enum because they are not public. The full source code is available in the chapter2.customswipe.CustomSwipe.java class.

So, at this moment, we already have a fully customizable swipe type. Now we add the swipeCustom() view action.

The swipeCustom() method first sets the swipe duration and then performs GeneralSwipeAction with our CUSTOM swipe type. Again, we have to paste the translate() method from inside the GeneralSwipeAction class, as it cannot be accessed from outside of the class.

Creating Custom RecyclerView Actions

The RecyclerViewActions class provides a limited amount of actions that can be used inside a recycler view or recycler view item. For example, clicking on the whole TO-DO item in the TO-DO recycler view is useful and can be used to open item details. But what if we need to click on the checkbox to mark a TO-DO item as done. Of course, we can do this based on position. As an engineer who owns the test data, I have the full control over each TO-DO name and I can make all the names unique. This enables me to identify each TO-DO item based on its name and then narrow down the focus to the specific element inside the TO-DO item. In our case, we want to click on the checkbox. Take a look at how this custom recycler view action may look on the clickTodoCheckBoxWithTitle() method from the CustomRecyclerViewActions.java class.

The perform() method is doing the heavy work here—we already can rely on the fact that our view is RecyclerView. Then we get the adapter from it and ensure that the adapter is an instance of the TasksFragment.TasksAdapter class. After that, we iterate through each item inside the adapter and fetch an item title from TextView with an ID of R.id.title. If the item’s title is equal to the title from TaskItem, we search for the CheckBox element with a R.id.todo_complete ID and call a click action on it. In the end, we loop the main thread for a short period of time to let the application handle our tap event. If a TO-DO with the expected title doesn’t exist in the list, it will throw an exception with the help of Espresso’s PerformException class.

Creating Custom Matchers for Simple UI Elements

In this case, BoundedMatcher is the perfect candidate since it returns the Matcher<View> type but will operate only on elements with EditText type. Refer to the CustomViewMatchers.java class, which contains the withHintColor() matcher implementation that matches the color of the EditText hint.

Here, BoundedMatcher enables us to match the EditText view that’s the subtype of the Android View type and return to the end object of the Matcher<View> type. When the EditText element is identified on the screen, its hint color is compared to the expected color, returning a true or false value. Whenever a true value is returned, it means that EditText with the expected hint color was found.

Here is how the usage of the withHintColor() matcher looks in a real test case (refer to the CustomViewMatchers.java class for more details).

Implementing Custom RecyclerView Matchers

From my point of view, the RecyclerView matchers are the most hidden part in Espresso. The Android documentation does not explain how to implement them but, based on the past examples from this book, you may guess that the BoundedMatcher class can be used to create them.

We will refer to our sample application and create the RecyclerView matcher that matches the TO-DO item in the TO-DO list based on its title. Again, the title is assumed to be unique since we have the full control over the test data.

Here it is important to understand the application under test and know which ViewHolder to use. In the sample, we put TasksFragment.TasksAdapter.ViewHolder as the second parameter into BoundedMatcher. Whenever our matcher identifies elements on the screen with the type, we retrieve the title from the holder and compare it to the title we provided as a matcher parameter.