Automation Testing Part 3: Mobile Automation Testing with Appium

This is post 3 of 3 in the series “Automation Testing Series”

1. Automation Testing Part 1: Where Do I Start?
2. Automation Testing Part 2: API Testing Using Rest-Assured
3. Automation Testing Part 3: Mobile Automation Testing with Appium

In my first post, I explained a simple three-step process to start any automation testing. In the second post, I explored REST API testing, its importance, how to create tests using Rest-Assured and how to integrate them with your ongoing development efforts. In this third and final installment of the automation blog post series, we will cover mobile automation testing, specifically using Appium. When it comes to creating mobile automated tests, there is no better option than Appium. We will discuss why this is the case, where and how we can apply these tests and, as always, integrate these subjects into current development efforts.

Overview

Mobile development has become an increasing industry over the past years, whether it’s native or hybrid-based applications, Android or iOS, apps are everywhere and it is very important to ensure that they work as desired. To achieve certainty in this regard, automated tests can be easily built on top of these applications to continuously test their overall features and confirm that the outcome is as expected. Now, let’s dig into Appium and show how to put it to good use.

Appium

Appium is an open-source testing automation tool used specifically for testing mobile applications and mobile web pages on both iOS and Android platforms. Since it has the advantage of being cross-platform, it allows for testing of the platforms, applications and mobile browsers to be done using their common API. What does this mean specifically? That code can then be reused to perform the same tests on different platforms. However, to run these tests on multiple platforms there are a few things to be taken into consideration—setting up your capabilities properly, for example, which will be discussed later in more detail. First off is installing Appium, which can be easily accomplished with the package manager of your preference. For an example using npm, installation would be done with the following command:

npm install -g appium

With Appium properly installed, I would also highly recommend installing the Appium desktop application, as it will help tremendously in identifying UI elements within our applications, which is very important when trying to interact with them. Now, let’s begin with our example code. The first step is to create the Desired Capabilities. Let’s recall that the capabilities act as our “settings” and define a number of these so that tests can run accordingly. This means that capabilities are in charge of making a test run on one platform or another, on a simulator, emulator or real device of our choosing, as well as several other properties. Let’s take a look at how the capabilities setup would be on an iOS platform.

private IOSDriver driver;
DesiredCapabilities caps = new DesiredCapabilities();
caps.setCapability("platformName", "iOS");
caps.setCapability("platformVersion", "10.1");
caps.setCapability("deviceName", "iPhone 5"); // information obtained by executing "instruments -s devices on Terminal
caps.setCapability("app", "/Users/test/Downloads/demo_application.app"); 
driver = new IOSDriver(new URL("http://127.0.0.1:4725/wd/hub"), caps);

Let’s also look at how it would differ when setting up the capabilities on Android.

private AndroidDriver driver;
DesiredCapabilities caps = new DesiredCapabilities();
caps.setCapability("platformName", "Android");
caps.setCapability("platformVersion", "6.0");
caps.setCapability("deviceName", "Nexus 4"); // information obtained from Android Virtual Device Manager
caps.setCapability("app", "/Users/test/Downloads/demo_application.apk"); 
driver = new AndroidDriver(new URL("http://127.0.0.1:4725/wd/hub"), caps);

Keep in mind that the Appium API works on multiple platforms, meaning that tests can be easily manipulated via a conditional or initial setup to run on both of the platforms mentioned above and still execute the same test, which presents a major advantage for applications developed using different mobile OS systems. After defining your capabilities, you need to identify your UI elements and define them in your code by using a “locator,” or a means of recognizing these elements so that users can interact with them and build their test. Popular locator strategies include Id, Class or XPath. These elements can then be stored into variables and used later.

public static final String USERNAME_TEXT_FIELD = "login_username_textfield";
public static final String PASSWORD_TEXT_FIELD = "login_password_textfield";
public static final String LOGIN_BUTTON = "login_login_button";
public static final String DASHBOARD_LOGO = "Logo_Dash";

DeviceElement usernameTextField = new DeviceElement(MobileBy.id(MobileLocators.USERNAME_TEXT_FIELD), driver);
DeviceElement passwordTextField = new DeviceElement(MobileBy.id(MobileLocators.PASSWORD_TEXT_FIELD), driver);
DeviceElement loginButton = new DeviceElement(MobileBy.id(MobileLocators.LOGIN_BUTTON), driver);
DeviceElement logoDashboard = new DeviceElement(MobileBy.id(MobileLocators.DASHBOARD_LOGO), driver);

But now the question is: “How do we know what locators to use on which element if we can’t see the code?” That’s where the Appium desktop client application comes in handy. This tool can be used not only to interact with an application on a specific platform but also to identify each mobile UI element on any screen and display details for that element, as shown below.

Now that we have defined our UI elements to be interacted with, let’s create our test. As done before in this series, we will use Cucumber and take a BDD approach to the creation of these examples. In this particular case, let’s do a simple login scenario.

Scenario: Validate successful login to the app
    Given I launch the application
    And I enter a valid username "test.user" with password "tester123"
    When I tap on Sign In
    Then welcome page should be displayed

Now that we have defined our feature file and the structure of the test, let’s create the essence of our test, which would be the mobile login page object class. If we are to follow a page object-oriented approach, in this class we would define the interactions of the UI elements defined earlier to achieve the goal of the test, which is to properly log in to the application.

public LoginMobileObject enterValidCredentials(String username, String password) {
    usernameTextField.sendKeys(username);
    passwordTextField.sendKeys(password);
    return this;
}

public LoginMobileObject tapSignIn() {
    loginButton.click();
    return this;
}

Once we create these methods, we call them within our step definition class in order to execute these calls.

@And("^I enter a valid username \"([^\"]*)\" with password \"([^\"]*)\"$")
    public void iEnterAValidUsernameWithPassword(String username, String password) throws Throwable {
        loginMobileObject.enterValidCredentials(username, password);
    }

    @When("^I tap on Sign In$")
    public void iTapOnSignIn() throws Throwable {
        loginMobileObject.tapSignIn();
    }

Now with our step definitions ready, we make assertions from the results that are given from the UI interaction. These assertions can vary between asserting if an element is present, or a specific page was shown, or the opposite: that no error happened. The sky is the limit here; assertions are made on demand.

@Then("^welcome page should be displayed$")
public void welcomePageShouldBeDisplayed() throws Throwable {
    loginMobileObject.assertLogoIsDisplayed();
}


public LoginMobileObject assertLogoIsDisplayed() {
    Assert.assertTrue(logoDashboard.isDisplayed());
    deviceDriver.quit();
    return this;
}

Finally, all that is left is to run our test. As mentioned at the beginning, Appium is an open-source tool and can be used in a number of different programming languages, including Java. Given that fact, and just as stated in the previous blog post, it can easily be integrated into any build tool of your preference: Gradle, Maven or any other that’s executed in an automatic parallel way.

Also, as we mentioned before, using a BDD approach and Cucumber makes it easy to integrate a report runner like Cucumber-Reporting. This, integrated into a Jenkins job that executes the task from the chosen build tool, will have resulted in a successful automated tool base to test our mobile applications and their desired behavior.

Conclusions

Appium is by far one of the best tools out there for mobile automated testing, as it has an easy, standards-driven approach for creating tests, supports multiple platforms using the same code base, and is open-source code, allowing for it to be run with a number of programming languages. With all of these advantages, the Quality Assurance department of any team can take advantage of this and begin creating automated test suites for their mobile applications without the need to separate the code base or their methodologies, ensuring high-quality tests in a very short period of time.

—