How is uiController.loopMainThreadForAtLeast different from Thread.sleep?

Issue

In this video from Google I/O 2016, Wojtek Kaliciński recommends using uiController.loopMainThreadForAtLeast instead of Thread.sleep in Espresso tests. Granted, the context is around Idling Resources, but what's the difference between the two and why is one better than the other?

Solution

Espresso uses a queue to check if app is idle.

Thread.sleep(x) = //Waits x 
uiController.loopMainThreadForAtLeast(x) // Waits x + more if app is still not idle

Now both of this are really bad approaches, that will result in some problems in production code.

1. Espresso can detect if app is idle if you are using AsyncTasks but in some scenarios it can't. So even when your app isn't idle, uiController.loopMainThreadForAtLeast(x) will be skipped.

2. Using IdlingResources inside production code to specify when app is not idle is not a good solution. You shouldn't change production code to test your app and idling resources checks if app is idle with 5 second intervals which will cause lots of overhead in your tests. Assume you have 100 test cases where you will experience this interval, the overhead you will experience will be huge

3. Using Thread.sleep(x)by itself is obviously a bad idea. As your tests needs to be stable regardless of the speed of internet connection, phone etc you shouldn't be waiting a fixed amount of time. And you can't know how much time you need to wait when you request something from a server so x you decide will either be too big or too small.

The best solution is to check if the target view you have in your assertion/action exists and if not check the target view again after X seconds (where X is a small number like 200 millis). Also using Thread.sleep() worked better for me than using uiController.loopMainThreadForAtLeast() when my app was showing animations (even when animations were closed from testOptions and phone settings)

Answered By - Prethia