Espresso vs Robotium

espresso vs robotium

15 June 2021 Stephan Petzl Leave a comment Tool comparisons

Robotium and Espresso both use Android Instrumentation to inspect and interact with the Android apps under test. In this article, we’ll compare their advantages and challenges.

The Robotium community made a sophisticated effort to create an Android test automation framework that has full support for native and hybrid applications. It makes it easy to write automatic black-box UI tests for Android applications. With the support of Robotium, test case developers can write function, system, and user acceptance test scenarios, spanning multiple Android activities.

However, there are some things to keep in mind if you decide on one or the other.

The major advances in Robotium over Espresso


Robotium is an open-source project that is driven by a real community. Compared to the development of Espresso which is mostly developed by Google.

Black box testing

Robotium features black box testing, meaning you don’t need to have access to the app’s source code.

Test view apps

Robotium allows you to test web view apps or apps that use a web view as part of their UI.

The major advances in Espresso over Robotium


Development of Robotium stalled in September 2016. There are 90 open issues, which haven’t really got much attention in the last years. Espresso is still actively supported and improved by Google.

Espresso supports all major API versions

Well-defined, documented, and predictable API

You tell the framework how to locate a UI element using standard “hamcrest” matchers. You can instruct it to perform an action or check an assertion on the target element. In contrast with Robotium’s API, that makes you choose one out of 30+ click methods. Further, Robotium exposes methods, which allow you to operate on objects outside of the main thread which can lead down a rabbit hole of unforeseen adventures.


By default, instrumentation test logic runs on a different thread than UI operations. Without synchronization of test operations with UI updates, the tests will be prone to flakiness – i.e. will fail randomly because of timing issues. Although you might not notice this fact in the beginning, you will run into situations that require additional wait or synchronization. This is far from trivial to solve. Espresso takes care of thread safety – at least to some degree. More complicated apps also will require implementing idling resources, which have their own downsides.


Because Espresso has access to your source code, it can provide helpful insight into the type of error you are facing in case of a crash. You can also enhance Espresso error handling with your own customized failure handler. Robotium suffers from inconsistent failure handling.

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