Mobile Testing Frameworks

Locating the Mobile Application

When you write an Appium test script, the most basic component is the DesiredCapabilities object, which sets the parameters of your test, such as the mobile platform and operating system you want to test against. Within that object, one of the required capabilities is Application Path, or the app desired capability. One of the advantages of the Appium architecture is that the application you want to test can be hosted anywhere, from a local path to any other web host on the network, since the Appium server will send the commands it receives from the client to any application path you specify. Practically, you have three options. 

curl -u <$SAUCE_USERNAME>:<$SAUCE_ACCESS_KEY> -X POST -H "Content-Type: application/octet-stream" \
https://saucelabs.com/rest/v1/storage/<sauce_username>/<upload_filename>?overwrite=true --data-binary @<path/to/your_file_name>

Creating a WebDriver Instance

The WebDriver instance is the starting point for all uses of the Mobile JSON Wire Protocol.

You create an instance of the WebDriver interface using a constructor for either Android or iOS. For mobile native application tests, you set both the platform and browser to test against by setting the browserName desired capability. 

Once you have created an instance of the WebDriver interface, you use this instance to invoke methods, such as tap and swipe, to access other interfaces used in basic test steps. You do so by assigning the instance to a variable when you create it, and by using that variable to invoke methods.

WebDriver Examples

These psuedo-code examples illustrate how to instantiate iOS and Android WebDriver objects in the various Appium language bindings.

WebDriver driver = new iOSDriver<WebElement>( new URL("https://ondemand.saucelabs.com/wd/hub"), capabilities);

WebDriver driver = new AndroidDriver<WebElement>( new URL("https://ondemand.saucelabs.com/wd/hub"), capabilities);

desired_caps = {}
desired_caps['platformName'] = 'iOS'
desired_caps['app'] = PATH('../../apps/MyIOS.app.zip')
self.driver = webdriver.Remote('https://ondemand.saucelabs.com/wd/hub', desired_caps)

desired_caps = {}
desired_caps['platformName'] = 'Android'
desired_caps['app'] = PATH('../../apps/MyIOS.apk')
self.driver = webdriver.Remote('https://ondemand.saucelabs.com/wd/hub', desired_caps)

const opts = {
  capabilities: {
    platformName: "iOS",
    app: "/path/to/the/downloaded/MyiOS.app.zip",
  }
};

const client = wdio.remote(opts);

const opts = {
  capabilities: {
    platformName: "Android",
    app: "/path/to/the/downloaded/MyAndroid.apk",
  }
};

const client = wdio.remote(opts);

opts = { caps: { platformName: :ios, app: '/path/to/MyiOS.app'}, appium_lib: { wait_timeout: 30 }}
appium_driver = Appium::Driver.new(opts, true)
appium_driver.start_driver

opts = { caps: { platformName: :android, app: '/path/to/MyAndroid.apk'}, appium_lib: { wait_timeout: 30 }}
appium_driver = Appium::Driver.new(opts, true)
appium_driver.start_driver

var sauceURL = "https://ondemand.saucelabs.com/wd/hub";
var driver = new IOSDriver<IWebElement>(new Uri(sauceURL));

var sauceURL = "https://ondemand.saucelabs.com/wd/hub";
var driver = new AndroidDriver<IWebElement>(new Uri(sauceURL));

Locating Application Elements

In order to find elements in a mobile environment, Appium implements a number of locator strategies that are specific to, or adaptations for, the particulars of a mobile device. Three are available for both Android and iOS:

#python example
driver.find_element_by_accessibility_id('my_accessibility_identifier')

#python example
driver.find_element_by_class_name('android.widget.DatePicker')

#java example
import org.openqa.selenium.By; 
import org.openqa.selenium.WebElement; 
WebElement emailInput = driver.findElement(By.id("fbemail"));

#python example
driver.find_element_by_xpath('//UIAApplication[1]/UIAWindow[1]/UIATextField[1]')

Best Practices for Identifying Application Elements

It is always best to use an element locator that uniquely identifies the element, like an id or an accessibility id. Class names and xpath are best used only when IDs are not available. Multiple elements can have the same class name, and using xpath searches through the entire markup to find the element, which can slow down your tests.

Performing Actions on the Application Elements

Once you've identified the mobile elements you want your test to interact with, the next step is to interact with them. You perform an action on a mobile element by invoking an interaction method on an instance of the WebElement interface.

The WebElement interface declares basic interaction methods including:

• The sendKeys method, to enter text
• The clear method, to clear entered text
• The submit method, to submit a form 

Example

This example first invokes the sendKeys method to enter text in the username and password elements, and then invokes the submit method to submit the login form. 

emailInput.sendKeys("SauceIsAwesome@email.com");

emailInput.submit();

Anticipating the Application Response

When you click a Submit button, you know that you have to wait a second or two for your action to reach the server, and for the server to respond, before you do anything else. If you're trying to test the response, and what happens afterwards, then you need to build that waiting time into your test. Otherwise, the test might fail because the elements that are expected for the next step haven't loaded into the browser you. The WebDriver API supports two basic techniques for anticipating browser response by waiting: implicit waits and explicit waits . 

Wait Strategies

driver.manage().timeouts().implicitlyWait(10, TimeUnit.SECONDS);

import org.openqa.selenium.support.ui.ExpectedConditions; 
import org.openqa.selenium.support.ui.WebDriverWait; 
WebDriverWait wait = new WebDriverWait(driver, 10); WebElement messageElement = wait.until( ExpectedConditions.presenceOfElementLocated(By.id("loginResponse")) );

Running Tests and Recording Results

Running tests and recording test results is the ultimate purpose of your test script: you run tests in an automated test script in order to evaluate function and performance in the AUT, without requiring human interaction.

Test Frameworks

To run test and to record test results, you use methods of a test framework for your programming language. There are many available test frameworks, including the frameworks in the so-called XUnitfamily, which includes:

• JUnit for Java
• NUnit for C#
• unittest or pyunit for Python
• RSpec for Ruby

For some programming languages, test frameworks other than those in the XUnit family are common - for example, the RSpec framework for Ruby. The Sauce Labs Sample Test Framework repos on GitHub contain over 60 examples of test frameworks set up to work with Sauce Labs. 

Test Assertions

Most test frameworks implement the basic concept of an assertion, a method representing whether or not a logical condition holds after interaction with an AUT. Test frameworks generally declare methods whose names begin with the term assert and end with a term for a logical condition, e.g. assertEquals in JUnit. Generally, when the logical condition represented by an assert method does not hold, an exception for the condition is thrown. There are various approaches to using exceptions in most test frameworks. The SeleniumHQ documentation has more detailed information on using both assertions and verifications in your tests. 

Recording Test Results

Recording of test results can be done in various ways, supported by the test framework or by a logging framework for the programming language, or by both together. Selenium also supports taking screenshots of web browser windows as a helpful additional type of recording. Because of the wide variations in recording technique, this beginning section omits recording, instead emphasizing a simple approach to applying a test using an assert method. The scripts in Sauce Labs Demonstration Scripts include examples of setting up reporting of test results to Sauce Labs, as do the framework scripts in the Sauce Labs Sample Test Frameworks github repos. 

Example

The following example runs a test by asserting that the login response message is equal to an expected success message:

import junit.framework.Assert;
import junit.framework.TestCase;

WebElement messageElement     = driver.findElement(By.id("loginResponse"));
String message                 = messageElement.getText();
String successMsg             = "Welcome to foo. You logged in successfully.";
assertEquals (message, successMsg);

Concluding the Tests

The quit Method

You conclude a test by invoking the quit method on an instance of the WebDriver interface, e.g. on the driver variable. 

The quit method concludes a test by disposing of resources, which allows later tests to run without resources and application state affected by earlier tests. The quit method:

• quits the web browser application, closing all web pages
• quits the WebDriver server, which interacts with the web browser
• releases driver, the variable referencing the unique instance of the WebDriver interface. 

Example

The following example invokes the quit method on the driver variable:

driver.quit();