Adding Espresso UI tests with Idling Resources
You may want to read the Spanish version of this article in Droid-Latam’s publication
Espresso is the framework we use while writing UI tests for our Android apps. In general terms its use is quite easy, however, writing UI tests when some synchronization process (i.e querying data from a remote datasource) is made within the app, may be tedious because Espresso needs to know when the synchronization ends (the app is idle). This is when working with Idling Resources comes to the context.
Imagine we are UI testing a screen that has a list of something, then the consume of a get API endpoint needs to be done, and we have to wait for the API response, populate the list with each item.
This process (getting, loading and displaying the data)may take from some milliseconds up to a couple of seconds. Espresso doesn’t really know when our app is idle because it only sees 15 ms in the future, then if the response takes more than this the UI test will fail.
Espresso provides a container class into which we can place our app’s idling resources (IdlingRegistry) that introduces minimal overhead to the app, and Android Devs team provides a recommended approach as follows:
The idea is to perform only the registration and unregistration operations in our tests classes and placing the idling resource logic itself in our app’s production code, which means that we have to create our idling resource “marker” within our production code, then before the app calls the api endpoint we set a mark indicating espresso that the process is starting and just after we have the result we let espresso know about it, then it can continue with the test after all data is obtained.
Step by Step
Firstly, register and unregister the idling resources within @Before and @After test methods respectively:
Secondly, creates the IdlingResource (EspressoIdlingResource), and for this case we use a CountingIdlingResource, that comes with Espresso and lets us call increment each time we start a task and decrement when it finishes. That way we can control more than one task running concurrently. This resource is placed within a production package, not androidTest package:
Finally, call increment() and decrement() methods within our production code:
And this is all, now we have the chance to UI test with Espresso screens that have long process using IdlingResources.
Remember that we can use Custom Rules when repetitive tasks are being written within our tests, then you can check this article that shows how to do it easily.
Idling Resources in the Production Code?
To finish, you may be asking yourself: should I use Idling Resources in our production code? And to answer the question I’d like to paraphrase Jose Alcérreca from Android team:
On the one hand, they’re very easy to use and they do make your code more testable. On the other hand, you’re adding code to an app that will be run by potentially millions of users but will do… nothing.
If you go this route, you should limit the negative effect in production. For example, if you are using a CountingIdlingResource from an object, create different versions of this object for debug and release (or for different flavors). The released version should do nothing:
All the code within an actual project can be found in this branch of a repo I’ve been sharing with you.
Also, you may refer this codelab and this article with some examples from Android Developers for more information and practical examples about Espresso.
