Hello everyone,
Today’s guest is Tobias Doll, a Test Automation Engineer in the Mobile Development Department of Deutsche Welle (DW). DW is a German public international broadcaster with goals to convey Germany as a “liberal, democratic state based on the rule of law”, to produce reliable news coverage and to provide access to the German language.
With rich experience in mobile QA, Tobias is excited to share some insights on how to explore the possibilities of Espresso and how to fully leverage the power of Gherkin with Espresso for Android test automation. If you want to move on from Calabash and look for a new way to handle your Android app testing, this article is for you. Read on.
Back in the days when I was mainly doing QA for websites and web apps, my go-to tool for doing test automation was, of course, Cucumber and all the tools from its rich ecosystem. I guess everybody who is in touch with writing test cases, managing test cases and automating test cases wouldn’t want to miss it! With the Gherkin DSL and its implementation, you’re able to reuse the testing code in an easy and understandable way.
Naturally, when I started to work with native mobile apps for Android, I was looking for something similar. While Calabash offers a Cucumber workflow with tests written in Gherkin, it has an uncertain future, due to it not being actively developed further. Besides, we were much more impressed by the possibilities of Espresso, Google’s own test automation framework for Android.
What I found was Green Coffee, a library that lets you write your Android UI-tests as features in Gherkin and hook them up with steps using Espresso features.
Instead of setting up a new sample project, let me just refer you to Maurizio Togneris excellent example implementation: [https://github.com/vndly/green-coffee-example] It consists of a small set of activities and corresponding tests.
For the setup, you need the following dependencies in your Gradle file.
For this blog, we’ll concentrate on the first activity, which is a login activity with two EditTexts, one for the username, one for the password. Under these, there is a button for triggering the login action.
Our first feature could read like the following:
Feature: Login screen to authenticate users
- Scenario: Invalid password
- When I introduce a valid username
- And I introduce an invalid password
- And I press the login button
- Then I see an error message saying ‘Invalid credentials’
What you can see at first sight is the possibility to reuse steps in different scenarios.
For the set up it doesn’t really matter where you put your features. However, we like to put them into assets.
The tests themselves consist of Java classes which inherit from GreenCoffeeTest. A test for our login feature could look like the following:
So, what does this all mean?
- The name of the test class. It has to inherit from
GreenCoffeeTest
- In your
ActivityTestRule name the activity that should get started
- Where Green Coffee can find your feature file
- The arguments for
start() are classes with the step definitions
- Here would be the place to do some kind of setup before a scenario starts
The java classes with the steps also inherit from a Green Coffee class, in this case GreenCoffeeSteps. The connection between the steps in the feature files and the methods happens via annotations.
When all files are present the only thing left to do is to start the test. The tests can be executed like regular Espresso tests via the IDE or via Gradle.
And of course, the tests can be used on Bitbar Testing in the same way as any other Espresso tests (below is a screenshot about one of our test runs at Bitbar Cloud). For us, that means having our tests packed up in test suits which are tested at Bitbar Cloud via the Gradle plugin.