mobile automation made awesome

Isaac Murchie • Developer, Ecosystem & Integrations • Sauce Labs

@AppiumDevs • @imurchie • @saucelabs

Selenium in the palm of your hand: Appium and automated mobile testing

SeConf 2014 • Bengaluru, KarnatakaSept. 6, 2014

Mobile TestingDo we need to test our apps?

On what devices?What tools are available?

The Problem

• Device fragmentation• Test tool fragmentation• Poorly supported automation

options

• iOS UI Automation• Only works for iOS

devices• JavaScript library• Badly documented• Not scalable: Local

only, one-test-at-a-time

• Android uiautomator• Only works for

Android devices• Java library, deployed

to the device• Not scalable: single

test running on the device

Motivation

Both Apple and Google provide rudimentary testing tools that suffer from the same

fragmentation as the devices themselves.

We need an open framework that can abstract those details away and provide

cross-platform test support in the languages the testers are using.

What is Appium?

+ =

Overview• Open source• Active development• Active community• JavaScript and Java

ArchitectureShould be familiar to Selenium

users.

Local (Client-side)

Uses thin wrappers around the Selenium clients, to add mobile

functionality.

Remote (Server-side)

• Depends on iOS UI Automation and Android uiautomator

• Accepts JSONWP commands, and proxies to the device

Development of Appium

At the beginning, the standard was ill-fitting for use in the mobile

domain.

1. Map Selenium commands to mobile functionality

2. Repurpose commands for mobile-specific functionality

3. Send errors for commands that make no sense

Selenium 4.0 (?) and mobile testing

Mobile-specific commands are mapped to their own endpoints in

the Mobile JSON Wire Protocol

Also a provision for vendor-specific endpoints (e.g., /appium/device/

lock)

Recognizable WebDriver actions

• Element locating• Timeouts• Screenshots• Click, back, forward, refresh

Demo of WD functionalitydescribe "Handling UITextFields" do it "should be able to fill in text fields" do rnd = Random.new n1, n2 = rnd.rand(100), rnd.rand(100)! find_element(:name, "Editing").click sum_el = find_element(:name, "Sum") add_btn = find_element(:name, "Add")! el = find_element(:name, "TextField 1") el.send_keys("#{n1}")! el = find_element(:name, "TextField 2") el.send_keys("#{n2}")! sum_el.text.should eq "" add_btn.should be_enabled! add_btn.click sum_el.text.should eq "#{n1 + n2}" endend

Mobile-specific functionality

• Special locator strategies• Contexts• Network connections• Gestures

Gestures

Need for abstraction of the (very significantly different, and complex) implementation details

Should map logical steps to build complex multi-part gestures

var target = UIATarget.localTarget();target.touch([ {"touch":[{"x":160,"y":208}], "time":0.2}, {"touch":[{"x":35,"y":183}], "time":0.4}, {"touch":[{"x":35,"y":183}], "time":5.4}, {"touch":[{"x":160,"y":208}], "time":5.6}]);

final ReflectionUtils utils = new ReflectionUtils();!final Method touchDown = utils.getControllerMethod("touchDown", int.class, int.class);touchDown.invoke(utils.getController(), 240, 438);!final Method touchMove = utils.getControllerMethod("touchMove", int.class, int.class);touchMove.invoke(utils.getController(), 240, 292);!Thread.sleep(5000);!final Method touchMove = utils.getControllerMethod("touchMove", int.class, int.class);touchMove.invoke(utils.getController(), 240, 300);!final Method touchUp = utils.getControllerMethod("touchUp", int.class, int.class);touchUp.invoke(utils.getController(), 240, 400);

iOS Android

Selenium

var action = new TouchAction(driver);action .press({ el: el }) .moveTo({ el: el2 }) .wait({ ms: 5000 }) .moveTo({ el: el }) .release() .perform();

Demo of iOS Gestures

Obstacles along the way• Sketchy underlying systems• Disconnect between capabilities

of different systems• Disconnect between what is built

(or buildable) and what users want

• Typical issues of building a stable system from inherently flaky parts

The Future