This article is supposed to provide alternatives for reducing flaky tests. I agree that it is very impractical to change production code to make Idling Resources work with Coroutines.

However, using `waitUntil` APIs is the epitome of flakiness! These `waitUntil` APIs utilize timeouts. However, which value should be used for a timeout? Perhaps on my machine 1 second is enough. But what about some CI machine? 1 second might be enough in cases the CI machine is not under heavy load, but it might also be completely inadequate under heavy load times.

In those scenarios, what is a good value to wait… 5 seconds? 10 seconds?

Using waits is a way of introducing flakiness into tests, not removing it. I can’t agree with the conclusion of the article to use waitUntil APIs to get rid of flakiness.

Coroutines and Flow is used as an example where using Idling Resources is nigh impossible. I agree. However, there are APIs to handle Coroutines in tests. The `StandardTestDispatcher` and `runTest` block.

Of course those can’t be used in Jetpack Compose’s UI tests. Because it is impossible to overwrite the main dispatcher, because the compose test rule then breaks down.

Implementing waitUntil APIs is very easy, so that’s the solution that was implemented by Google, but this is not fixing flakiness of tests. It is promoting WRONG testing practices.

The approach with waitUntil APIs is unmaintainable and should definitely not be promoted as the go-to solution as this article would have you believe.