The centerpiece of Espresso is its ability to seamlessly synchronize all test
operations with the application being tested. By default, Espresso waits for UI
events in the current message queue to be handled and for default instances of
AsyncTask to complete before it moves on to the next test operation.
However, there are instances where applications perform background operations, such as communicating with web services, using non-standard means, such as direct creation and management of threads.
In such cases, you have to use idling resources to inform Espresso of the app’s long-running operations.
Creating and registering idling resources
This interface needs to be exposed to the test or created within it and injected
into the application. Then, register one or more of your idling resources with
Espresso by calling
Espresso.registerIdlingResource() in the test setup.
Check out the Espresso idling resource sample.
Implementing idling resources
There are two common ways to implement idling resources:
- Counting running jobs: When a job starts, increment a counter. When it
finishes, decrement it. The app is idle if the counter is zero. This approach is
very simple and accounts for most situations.
CountingIdlingResourceuses this approach.
- Querying state: It might be more reliable to ask a work queue or an web client if it is busy. If the state is exposed, implementing an idling resource is trivial.
Note that there are idling resource implementations for popular libraries, such