15 June 2021 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
Open-source
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
Support
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.
Synchronization
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.
Debugging
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.
