Automation tests for an Android app using Appium (Part 1)

Automation tests for an Android app using Appium (Part 1)


In this post I’m going to talk about the steps for automating your Android application using Appium. By automation it is meant, execution of steps in a given scenario to ensure the application behavior is as per requirement. In this post I’m going to cover an example automating an Android application using Cucumber and BDD (Behavior Driven Development) approach.

Why Appium?

Appium is open-source tool that could be used for automating native, mobile web, and hybrid applications on iOS and Android platforms. I find the following points decision making for using Appium as your automation tool.

  • Large community
  • Cross platform solution
  • It is black-box automation testing tool
  • It is based on UIAutomator

The first point that I have added is the community, this is really important when choosing open source project for your production development. I’m saying development because automation testing is one sort of development when you have to write the scenarios, steps, methods, structure by yourself. For Appium you don’t need to have source code of the project, by adding the .apk file in the automation project, you can automate the Android application. If you have to test an Android application which is developed for Android 4.2+, you can use the Appium tool without any additional work because Appium is using UIAutomator for automating the UI.

Getting started!

Enough talking, let’s get started and automate some applications πŸ™‚
For this example I have used the following application Material Demo, and the author of this application isΒ author. I have chosen this application because it implements the material design, and has various elements that could be automated.

For this example I assume that you have installed the following requirements for using Appium:

  • Node.js
  • Android SDK with API >= 17
  • Appium
  • IDE (in my case IntelliJ CE)
  • Cucumber plugin for IntelliJ CE

Project structure

As mentioned previously for this example I’m going to use the BDD approach, and the project structure is the following:

  • Base folder
  • Screens folder
  • Steps folder
  • App folder
  • Features folder

Base folder is used for storing the class for reading the configuration, and the driver helper class used for inspecting the elements.
Screens folder is used for storing the classes that contain the logic for interacting with the elements on the displayed screen, for example: Login screen, Splash screen, etc.
Steps folder is used for storing the classes that contain the implementation of the steps defined in the feature files.
App folder contains the .apk file for which the automation scenarios are going to be written. If the application is already installed on the device, the .apk file doesn’t have to be placed in this folder.
Features folder contains the .feature files with the Scenarios and their steps.

Running the first scenario

The scenario below is written in the WizardScreen.feature file, and it is written in gherkin syntax. The purpose of this scenario is to choose the Social wizard, navigate through the screens, and validate that the Finish button is displayed once the final screen is reached.

Scenario: User has validated the flow of the wizard
  When The user has scrolled down the home menu to open the Wizard
  And The user has selected the Wizard option from the menu
  And The user has selected "Social wizard" from the list
  And The user has scrolled the wizard to the finish
  Then Validate the wizard is going to have text Finish at the final slide

In the animated image are discribed the steps which are automated for the scenario.

Show me the code!

In this section I’m going to describe the step defnitions for the scenario written in the WizardScreen.feature file. Ok 1, 2, 3, … Let’s go!

@When("^The user has scrolled down the home menu to open the Wizard$")
public void whenTheUserHasScrolledDownTheHomeMenuToOpenTheWizard() throws InterruptedException {

The annotation @When is used to define the step saved in the feature file. As you can notice the name of the scenario starts with ^ and ends with $, and these two characters are mandatory for each step definition. The variable homeScreen is actually a screen class that is saved in the screens folder. This class contains the logic for interacting with the elements on the home screen.

@And("^The user has selected the Wizard option from the menu$")
public void andTheUserHasSelectedTheWizardOptionFromTheMenu(){

@And ("^The user has selected \"(.*)\" from the list$")
public void andTheUserHasSelectedSocialWizardFromTheList(String listOption) throws InterruptedException {

@And ("^The user has scrolled the wizard to the finish$")
public void andTheUserHasScrolledTheWizardToTheFinish() throws InterruptedException {

As you can see each step definitions implements a specific method from a screen class. This approach allows the step definitions to be clean, and the main logic of the screen classes to be easily maintained, reused or refactored.
In order the scenario to have value, an assertion has to be added. The scenario assertion is performed in the Then step of the scenario, in my case the assertion is performed with the following step definition:

@Then("^Validate the wizard is going to have text Finish at the final slide$")
public void thenValidateTheWizardIsGoingToHaveTextFinishAtTheFinalSlide(){

In the step definition above, the assertion is checking whether the Finish text is displayed on the screen, which indicates the end is reached.

Ok, maybe at this point you are saying to your self, “That’s ok, but i haven’t seen any code about the element location.”. That’s why in the following section we are going to have a look in the screen classes that are implemented in the step definitions for interacting with the elements on each screen.

Locating elements

The elements located in HomeScreen, WizardScreens and SocialWizardScreen are using the default location strategy by the Selenium WebDriver. I mostly prefer location the elements by id (when there is available id), or by xpath when the element structure is a bit complex.

public void clickMenuButton(String menuTitle){
    MobileElement loginPagesButton = waitForElementPresent(By.xpath("//android.widget.ListView//android.widget.TextView[@text='"+menuTitle+"']"));;
public MobileElement waitForElementPresent(By by){
    WebDriverWait wait = new WebDriverWait(driver, appConfig.getIntegerProperty(AppConfig.PROPERTY_EXPLICIT_WAIT));
    MobileElement element = (MobileElement) wait.until(ExpectedConditions.presenceOfElementLocated(by));

    return element;

In the method clickMenuButton it is located the element from the menu on the left side. The location for this element is used with xpath. When using xpath for your location strategy you can increase the reusability of the screen elements, but this requires to be familiar with the usage of xpath. When locating the elements there is certain time that we have to wait for the elements implicit wait, explicit wait, fluent wait, in my case I’m using the explicit wait for locating the elements. This means the driver is going to wait for specific amount of seconds until the element is found. If the element is not found in the defined time, an exception is going to be thrown by the driver.


Here I’m going to end the first part of this post, the code and the whole example project could be downloaded from my github repository AppiumDemo. I hope you have gathered some information how to structure your project for your Appium automation, how to find the elements by using the selenium locator strategy, and why to use xpath instead of other locator strategies πŸ˜‰
In the next parts of this post I’m going to cover the ways how to inspect the Android elements, how to configure the Appium server, and some Android handy tips. If you find this example handy don’t forget to star the project; see you in the next posts πŸ™‚