Member-only story
Testing in Android Part 5: Idling Resources
Idling Resources from Espresso, CountingIdlingResource, and ComposeOkHttp3IdlingResource
Introduction
In this article, we’re going to learn about how to write integration tests that involve background tasks like API calls to update the UI using the Espresso Idling Resources feature. As I said Idling Resources is part Espresso not Compose, so we need to make a few customizations to make it work together.
We’ll start the article with the basic question, What’s Idling Resources, from there we’ll create custom Idling Resources to support Compose test cases and our use-case.
This is the final part of the series, I would highly recommend you to read the previous parts of this series before going further if you already haven’t:
- Testing in Android Part 1: Unit Tests
- Testing in Android Part 2: Integration Tests
- Testing in Android Part 3: End-to-End Tests
- Testing in Android Part 4: Mock API Calls Or Not?
- Testing in Android Part 5: Idling Resources? — You’re here
What is Idling Resources?
To understand the importance or necessity of Idling Resources, first, you should know the problem with asynchronous background tasks in integration tests.
Compose by default supports synching the asynchronous tasks like recomposing, etc. that it’s aware of, but there are a few things that compose is not aware of like making an API call in ViewModel to update the data in composables.
Custom background tasks like this are app-specific, and not related to compose, so to be frank it should not be aware. This is where the Idling Resources come to light, it does the heavy lifting of communicating the resources are not idle so the Compose test cases should wait until the resources are Idle.
This approach reduces the dependencies on one another by making Idling Resources feature from Espresso to tell the compose test cases that the app is busy processing and wait until it’s done.
