Automation tests for Mobile Web with Appium

Automation tests for Mobile Web with Appium

Introduction

Most of today’s web applications implement responsive design to gain more users in different device sizes. But by using this approach comes great responsibility from QA perspective, because the application has to be covered for Desktop, Tablet, and Mobile. If we had one test case (TC), and by executing the TC on all three devices, it would take us three executions. Some might not find this difficult, but if you have to cover the same web application on Android and iOS, and ensure it is working properly on Safari, Chrome, Android Browser, well now things are getting pretty messy (Not mentioning Android Tablets and iPads :)).

Why worry so much when we can automate most of the things. There are ways that can be achieved this:

  1. Using Selenium WebDriver for web automation, and changing the browser size to simulate different device size.
  2. Using Emulator / Real device to run the automation tests, in this case Appium.

The first case might work properly with the browser size, but we are not going to be 100% sure if it is going to work on a mobile browser, and we don’t want to make sanity checks just to be 100% sure. That’s why we are going to go with the second approach by using Appium.

Mobile Website automation

For the purpose of the demo project I have used the following website www.iliketofu.eu which is owned by AVOKADO d.o.o., and the reason for choosing this website is the interesting responsive design of the website. When writing automation tests for a mobile website you will have to combine a little bit from a mobile automation, and a little bit from a web automation. In the previous post I have been talking about the Appum inspector for inspecting the UI elements, well in this post I’m going to skip this part. The reason for this is that Appium inspector is not going to do much work for inspecting the UI elements on the web.

For inspecting the UI elements I have been using the following tools:

  • Firebug with Firepath for inspecting the UI elements on the web. If you prefer Chrome for inspecting the elements using ChroPath will do the job.
  • Firefox web developer tools, for resizing the layout, or if you prefer you can use add-on by your choice.

Project Structure & Configuration

For this demo is also used the BDD approach, and the project structure is consistent with the project structure of the previous demos for Android and iOS. The project structure is the following:

  • Base folder
  • Pages folder
  • Steps 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.
Pages folder is used for storing the classes that contain the logic for interacting with the elements on the displayed page, for example: Contact page, All Products page, etc.
Steps folder is used for storing the classes that contain the implementation of the steps defined in the feature files.
Features folder contains the .feature files with the Scenarios and their steps.

There is small difference between the configuration of this demo, and the previous Android and iOS demos. In the previous demos I had one configuration file, on the other hand in this demo I have used two configuration files, and we are going to see why. Below are described the properties included in config_app_android.properties and config_app_ios.properties files.

  • explicit.wait – This property is used to indicate the explicit wait time for locating the element.
  • appium.server.port – In this property add the Appium port, the default value is 4723.
  • automation.instrumentation – In this property is set the instrumentation that is going to be used for automating the scenarios. In this case should be set as Appium.
  • browser.name – In this property is set the browser which is going to be executed for the automation. In this case should be set to Chrome or Browser for Android and Safari for iOS.
  • platform.name – In this property is set the platform name that is going to be used, in this case should be set with Android.
  • device.name – This property contains the device name on which the automation tests that are going to be executed. (I’m going to describe below, how to list all devices)
  • platform.version – This property contains the Android version of the device, on which the automation tests are going to be executed.
  • url – The url of the website that is going to be tested.
  • device.udid – This property contains the UDID of the device, it is unique identifier for each simulator, and iPhone device.

I have talked a lot about the configuration, but I have never told you how you can set which configuration you are going to use for the automation testing. Well the secret is in the AppConfig class, currently I have added the file name as magic string, but according to your needs you can modify the logic accordingly. The following code defines which configuration file is going to be used for the automation suite:

File file = new File(classLoader.getResource("config_app_ios.properties").getFile());

With the current code the application is going to execute the automation suite for iOS. If you want to run the automation suite for Android just change config_app_ios.properties into config_app_android.properties.

Interacting with the elements

Regardless that the automation solution is used for Android and iOS we are going to use the same Page classes for locating the UI elements, Step classes for executing the steps in the feature file, and Feature file for defining the scenarios.

In the Page object classes the elements are located as WebElement, and the code for finding the WebElements is the following:

WebDriverWait webDriverWait = new WebDriverWait(DriverHelper.driver, Long.parseLong(appConfig.getProperty(AppConfig.PROPERTY_EXPLICIT_WAIT)));
WebElement element = webDriverWait.until(ExpectedConditions.visibilityOfElementLocated(by));

As you can see from the code structure the code used for interacting with the elements is the same as interacting with the elements on Firefox / Chrome / PhantomJS. Depending on the complexity of the Mobile Website certain strategy should be used for locating the web elements.

Conclusion

Here I’m going to finish the post about automation for mobile web, I hope now you have better understanding how the Mobile Web automation is performed, how to find and interact with the web elements, how to manage the configuration files, and most importantly how to run the automation suite. If you find this post helpful don’t forget to share it with your friends 😉

One thought on “Automation tests for Mobile Web with Appium

  1. Pingback: Testing Bits – 10/8/17 – 10/14/17 | Testing Curator Blog

Leave a Reply

Your email address will not be published. Required fields are marked *