Espresso is the Android test automation framework offered by Google. For the past few years I’ve had the pleasure of working with Espresso and I’d like to share a few features that contributed to this pleasurable experience.
Timing issues in tests are always unpleasant. Frameworks like Appium and Selenium Webdriver solve this by using implicit- and explicit waits where the framework polls until the element or view that you’re looking for is available. This means that sometimes your website or app is done rendering the contents and the requested view hasn’t appeared, but the framework will still keep polling until the wait time has elapsed. Espresso can avoid situations like these, because it’s able to monitor whether the app is idle and execute test code as soon as it is. This means that Espresso will never keep polling while the app has been idle for a while. The advantage is that tests are quicker and running tests on remote devices or cloud services won’t introduce unexpected timing issues.
Espresso is developed by Google and as such it offers tight integration with your app project in Android Studio. The resource ID’s you use in your app layouts are the same ID’s that you use in your tests. A refactor of ID’s in your app code will also refactor the ID’s in your test. On top of that, having access to your app code allows you to mock and stub dependencies. For instance network calls can be stubbed using OkReplay, intents can be intercepted and checked and shared preferences can be edited. In short, the integration with your app offers you more control over the app under test and makes your tests reliable. Another pleasant side effect is that it allows testers and developers to work together in a natural way.
I‘ve already mentioned it: Espresso test are fasts. For comparison I wrote 10 tests for a hybrid app using both Appium and Espresso. Locally Appium took 5 minutes to run the tests. Espresso ran the same tests in 49 seconds. Using a cloud service took Appiums number up to 10minutes, because Appium’s client-server model introduces extra latency. Espresso tests run on the device itself, so even when using cloud services the tests were done in under a minute. And that helps. Not just when running regression sets, but even more so when developing, and writing and refactoring tests.
If you’re looking for a way to automate those Android UI tests, I would definitely give Espresso a shot