In previous article, we talked about how to scroll to a certain position in RecyclerView in the test. In this article, we further discuss how to write a custom matcher and use it to scroll the RecyclerView.
Let’s say that we want to scroll to certain item in RecyclerView, but we don’t know the position. We can then create a custom Matcher, and use the matcher to determine which item to scroll to.
In part II, we wrote a test case to verify that the app can create a task and the task will be seen on the screen. In this part III, we will demonstrate one technique on writing tests that involves a RecyclerView.
First we repeatly add some tasks, and then we verify that the last added task is on display. Note that since we are using a RecyclerView, the last item might not be seen, so we need to scroll the RecyclerView before checking.
In Part I we talked about how to setup Espresso testing framework, what is the activity testing rule and how to use uiautomatorviewer to help us find id of the view quickly.
In this Part II, we will write some tests against a simple TODO list application. Lets get started.
About the App under test This is a very simple app with basically 2 screens. One to display a list of tasks:
If you are a Linux person and you want to follow the awesome Hand Made Hero, here are how I am doing it(on Arch Linux).
Install VirtualBox. Create a Windows virtual machine(at least Win7 + SP1, you can download a ISO image from here), pay attention to the hard drive size, 25G is too small, increase it to like 50G at least. In order to make the full scren mode work, we have to install something called Guest Addition.
The Espresso testing framework really makes it easy to write UI tests for Android. In this first installment, I will go through how to set it up and write our first test case.
Let’s get started.
Set up Espresso Add the following dependencies to your gradle build file.
dependencies { // Other dependencies … androidTestCompile 'com.android.support.test.espresso:espresso-core:2.2.2' } Understand the Rules in JUnit Why do they exist? We all know that in JUnit there is a setup method(annotated as @Before) and a teardown method(annotated as @After).
