20 October 2022 Leave a comment Espresso
Espresso is one of the most known testing frameworks, for testing Espresso is common practice. However, many people who work with Espresso for a longer time realize the framework uncovers some issues which are hard to tackle. In this article we’ll give you a very quick overview on the usage of Espresso, show a few challenges including their solutions, and introduce you to a couple of alternatives.
Why to use Espresso for UI testing?
Espresso is probably the most common framework for UI testing, probably due to its main advantages:
- Free and Open Source
- Maintained by Google
- Lots of flexibility
Testing with Espresso – challenges
Let’s have a look at the most common Espresso challenges.
Wait for view
While waiting for a view to show up is usually handled by Espresso itself, there might be cases where an app is doing work on another thread (fetching data from a server, calculating something) and therefore Espresso does not know about it.
Taking a screenshot when a test fails
Taking a screenshot when a test fails and organizing these screenshots can become messy once you handle multiple devices.
Waiting for network calls
Espresso can’t handle network calls automatically because it is not aware of other threads executing a network call.
Waiting for animations
Espresso does not wait for animations to finish which might cause issues.
Waiting for activity
Espresso might fail when waiting for the activity to open.
Why to avoid thread sleep
You should avoid thread.sleep. Still, you might run into situations where you find that your tests fail without a line of Thread.sleep(). Thus you will have to tell Espresso to wait till your data is fetched or your background process is finished.
Waiting for element
It’s a common issue that espresso does not wait for an element to show up before executing the next step, resulting in an error.
Espresso is not aware of background tasks (such as loading web content, playing an animation, background processing) and therefore can’t know when exactly to trigger the next action. That’s why you need idling resources.
Testing an app that has bits of Jetpack Compose
Here’s a short guide on how to conduct tests for Jetpack Compose.
There are a few relevant alternatives to UI testing with Espresso. A few examples are:
- Repeato, a no-code alternative to Espresso
- Appium, an open source alternative to Espresso
- Robotium, another coding alternative to Espresso
Check out this overview on Android test automation for more frameworks, including their pros and cons.
Tags: android, espresso, idling resource