# Deprecating idling resource libraries

DevFeed: [Deprecating idling resource libraries](<https://devfeed.tech/articles/deprecating-idling-resource-libraries-20933.md>)

Original publisher: [Read original article](<https://jakewharton.com/deprecating-idling-resource-libraries/>)

Published: 2025-02-19T00:00:00Z

Content type: article

Language: en

Sources: [Jake Wharton](<https://devfeed.tech/sources/jake-wharton.md>)

Topics: [Testing](<https://devfeed.tech/topics/testing.md>), [Monitoring](<https://devfeed.tech/topics/monitoring.md>), [Compose](<https://devfeed.tech/topics/compose.md>), [ui](<https://devfeed.tech/topics/ui.md>)

Tags: [blog-post](<https://devfeed.tech/tags/blog-post.md>), [compose](<https://devfeed.tech/tags/compose.md>), [espresso](<https://devfeed.tech/tags/espresso.md>), [monitoring](<https://devfeed.tech/tags/monitoring.md>), [testing](<https://devfeed.tech/tags/testing.md>), [tests](<https://devfeed.tech/tags/tests.md>), [ui](<https://devfeed.tech/tags/ui.md>)

## AI overview

The article announces the deprecation of the RxIdler and okhttp-idling-resource libraries. It argues that tests should wait for user-visible UI conditions rather than internal application mechanisms, and points to Compose testing APIs and custom condition-waiting approaches for View-based layouts.

## Source excerpt

When Espresso was made public a decade ago, one of its banner features was the "idling resource" concept. This monitored the main thread and any background thread pools to prevent your test from progressing until the app became idle. Waiting until idle generally increased the stability of tests since at that point the UI should be stable. We released RxIdler and okhttp-idling-resource for monitoring RxJava schedulers and OkHttp's dispatcher, respectively. Today I am deprecating both libraries. In the years since their release, I have become disillusioned with the idling resource mechanism-and I'm not alone. Like using R.id to target views, idling resources expose the internals of your application to the testing framework in a way that no real user can match. The point of building tests in the robot pattern was to describe interaction at a high-level. If you can't read a UI test to someone over the phone interacting with the real app then it probably encodes implementation detail. "Okay dad, now wait for OkHttp's Dispatcher to report itself as idle before clicking 'continue'." Yeah... no. What do we do as real users? We wait until some UI condition is met which signals our ability to progress. "Okay dad, now wait for the 'continue' button to turn green before clicking it." Much better. We don't care how the application is performing the work nor the means by which it signals the UI that it is complete. Moreover, test failures that occur based on condition waits are failures which can occur in the wild. I've been sitting on these deprecations and this blog post for a few years now. Telling you to switch to a new technique without actually demonstrating it is not great. Turns out that around the same time Google was also changing their tune on idling resources. That guidance has since been promoted to the official documentation as well. These links demonstrate how to wait on conditions using new built-in Compose testing APIs. For View-based layouts, you can write a custo