Testing with Espresso: use, challenges, and alternatives

android test automation via espresso

20 October 2022 Leave a comment Tech-Help

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.

Idling resources

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.

Espresso alternatives

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.

Like this article? there’s more where that came from.