Waiting in Espresso tests

This Note originally published on my Personal Blog here. Read original note so that you won’t miss any content.

What is «Waiting»?

Lifeguard from flaky tests.

What variety do we have?

Hmm, let me think… 🤔

We knew about Idling Resources.

Pros:

• It’s the most honest, fastest, and technically perfect way to wait;
• It doesn’t eat up the memory.

Cons:

• Sometimes it’s not a bit easier than writing production code;
• Sometimes we’ll have to touch production code;
• Most cases will probably require the own Idling Resource.

We heard about sleeps.

Pros:

• Kill me then.

Cons:

• We’ll probably wait longer than we need;
• We’ll perhaps wait less than we need.

We were guessing about the hacky way of injecting UiAutomator.

Pros:

• That’s something close to us since the time of Selenium.

Cons:

• We’ll have to set an excess addiction;
• We’ll be limited by minSdkVersion = 18;
• We’ll have to play with weird UiObjects.

Go on, what about something else?

Okay… 😏

Let’s try the hacky way using Espresso.

At first we have to extend ViewInteration class by adding new methods:

• isDisplayed(): Boolean
• doesNotExist(): Boolean
• waitForAppear(millis: Long): ViewInteraction
• waitForDisappear(millis: Long): ViewInteraction

Then we can try to use it in the tests:

Pros:

• Nothing is easier than use it for all the cases;
• We’re able to control the waiting timeout for each case.

Cons:

• Logcat will be littered;
• After all, it a bit eats up the memory (comparing with Idling Resources).

Conclusion

Waits are the delicate matter:

• Follow the deadlines, needs, requirements and sanity;
• Do whatever you want (using Espresso, of course 🧐);
• Enjoy! 😉