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,
There are a few relevant alternatives to UI testing with Espresso. A few examples are:
- Appium, an open source alternative to Espresso
- Robotium, another coding alternative to Espresso
- Repeato, a no-code alternative to Espresso
Check out this overview on Android test automation for more frameworks, including their pros and cons.
Like this article? there’s more where that came from.
- Testproject.io retired. What alternatives are there?
- Testing with Espresso: use, challenges, and alternatives
- Manual Testing vs Automation Testing: what is better and when to use it?
- How to solve “tool ‘xcodebuild’ requires Xcode, but active developer directory ‘/Library/Developer/CommandLineTools’ is a command line tools instance”
- How to report code coverage data from Flutter tests?