2. Contents
• Appium Background
• Appium Architecture
• Appium Installation on Mac
• Running Appium on Real Devices
• How Apple's XCUITest is different?
2
4. What is Appium?
• Appium is an open source test automation
framework for use with native, hybrid and
mobile web apps.
• Appium is “cross-platform”, means it allows
you to write tests against multiple platforms
(iOS, Android, Windows), using the same API
(WebDriver API). This enables code reuse
between iOS, Android, and Windows test
suites.
4
5. What are different App Types
• Native apps are those written using the iOS,
Android, or Windows SDKs.
• Mobile web apps are web apps accessed
using a mobile browser (Appium supports
Safari on iOS and Chrome or the built-in
‘Browser’ app on Android).
• Hybrid apps have a wrapper around a
“webview” – a native control that enables
interaction with web content.
5
6. Appium Philosophy
• You shouldn’t have to recompile your app or
modify it in any way in order to automate it.
• You shouldn’t be locked into a specific language
or framework to write and run your tests.
• A mobile automation framework shouldn’t
reinvent the wheel when it comes to automation
APIs.
• A mobile automation framework should be open
source, in spirit and practice as well as in name!
6
8. Appium Architecture
• An HTTP server written in Node.js that creates
and handles WebDriver sessions.
• Appium web server follows same approach as
Selenium WebDriver
• Receives HTTP requests from client libraries
through JSON
• Handles received requests in different ways,
depending on platform it is running on.
8
9. Client/Server Architecture
Appium is at its heart a webserver that exposes
a REST API. It receives connections from a client,
listens for commands, executes those
commands on a mobile device, and responds
with an HTTP response representing the result
of the command execution.
9
10. Session
• Automation is always performed in the context of
a session.
• Clients initiate a session with a server in ways
specific to each library, but they all end up
sending a POST /session request to the server,
with a JSON object called the ‘desired
capabilities’ object.
• At this point the server will start up the
automation session and respond with a session
ID which is used for sending further commands.
10
11. Desired capabilities
• Desired capabilities are a set of keys and values
(i.e., a map or hash) sent to the Appium server to
tell the server what kind of automation session
we’re interested in starting up.
• There are also various capabilities which can
modify the behavior of the server during
automation.
• Example: Set the platformName capability
to iOS to tell Appium that we want an iOS
session, rather than an Android or Windows one.
11
12. Vendor-provided frameworks
used by Appium
The vendor-provided frameworks used by Appium:
• iOS: Apple's XCUITest (iOS 9.3 and up)
• iOS: Apple’s UIAutomation (iOS 9.3 and below)
• Android 5.0+: Google’s UiAutomator V2
• Android 4.2+: Google’s UiAutomator
• Android 2.3+: Google’s Instrumentation
(Instrumentation support is provided by bundling
a separate project, Selendroid)
• Windows: Microsoft’s WinAppDriver
12
13. Why XCUITest?
• For iOS automation, Appium relies on system
frameworks provided by Apple.
• For iOS 9.2 and below, Apple's only automation
technology was called UIAutomation, and it ran in
the context of a process called "Instruments".
• Apple introduced a new automation technology,
called XCUITest, beginning with iOS 9.3.
• For iOS 10 and up, this will be the only supported
automation framework from Apple.
13
14. Why XCUITest?
• with iOS 10 / Xcode 8, Apple has removed the
older UIAutomation framework, which powered
Appium's iOS automation up to this point.
• When you specify a platformVersion of 10 or
higher, Appium will automatically use the
XCUITest automation backend.
• If you would like to run the XCUITest automation
backend with iOS 9.3, simply
specify automationName: XCUITest in your
desired capabilities.
14
16. Software Requirements
• Java
• The Eclipse IDE
• Xcode (8.0 or later)
• Xcode Apple Developer Tools (iPhone simulator
SDK, command line tools)
• Homebrew
• Node and npm
• The Appium Server
• The Appium Client Library (Java)
• Selenium WebDriver Java library
16
17. Java
• Java - Download & install Java SE
Development kit 8 for Mac OS X
Link:
http://www.oracle.com/technetwork/pt/java/ja
vase/downloads/jdk8-downloads-2133151.html
17
18. The Eclipse IDE
• Download & install Eclipse IDE for Java
developers
Link: http://www.eclipse.org/downloads/index-
developer.php?osType=macosx
18
19. Xcode
• Install Xcode (Version 8.0 or above)
• Xcode can be downloaded free from Mac App
Store
Note: To test an app in iOS 10 or above with
Appium, we have to use Xcode 8 or newer with
Appium 1.6 or newer.
19
20. The Appium Server
• You can install & run an Appium server using
o node.js
o using the application
20
21. Before You install Appium Server…
Before you install Appium using node.js, you
should have:
• Homebrew
• NPM - node.js package manager
The Appium server is written in Node.js; that's
why we need it to download Appium
21
22. Homebrew
• A package manager for macOS that complements
macOS.
• Homebrew helps you install applications that are
not installed by default on your MAC.
• It's all git and ruby underneath.
• The standard script installs Homebrew
to /usr/local so that you don’t need sudo when
you brew install
• Homebrew is designed to work without using
sudo.
22
23. Install/Uninstall Homebrew
(commands for terminal)
• Installing Homebrew ruby -e "$(curl -fsSL
https://raw.githubusercontent.com/Homebrew/install/
master/install)"
• How do I uninstall Homebrew?
To uninstall Homebrew, paste the command below in a
terminal prompt.
ruby -e "$(curl -fsSL
https://raw.githubusercontent.com/Homebrew/install/m
aster/uninstall)"
• How to check available options on brew:
brew help, man brew
23
25. Homebrew Doctor
• After installing the Homebrew, run command
brew doctor
• You'll get the message: your system is
ready to brew.
• If you don't get above message then try to fix
warnings and errors using the brew doctor
25
26. NPM
• npm is a Node.js package manager
• It is an online repository of open source
Node.js projects.
• It is command-line utility to package
installation
26
27. Installing Node.js and/or npm
• Install node.js using brew.
brew install node
• Once you install node, you can check version:
node --version
npm —version
Note: Don’t use the big green install button on
nodejs.org website or all npm commands will
require sudo.
27
28. Installing Appium using Node.js
• Install appium using node.js
$ npm install -g appium
Alert: Make sure you have not installed Node or
Appium with sudo, otherwise you’ll run into
problems later.
28
29. Run Appium
• To run Appium
$ appium (Run Appium)
• Now Appium server will be ready for
accepting requests of client.
[Appium] Welcome to Appium v1.6.0
[Appium] Appium REST http interface listener started on
0.0.0.0:4723
29
30. Appium Doctor
• To verify that all of Appium’s dependencies
are met you can use appium-doctor.
• Install it with:
$npm install -g appium-doctor
• run appium-doctor and supply the --ios or --
android flags to verify that all of the
dependencies are set up correctly.
$appium-doctor --ios
30
32. Stopping Appium Server
• Simply press CTRL+C in the same terminal
window to stop the Appium server.
32
33. Appium.app, Appium.exe
• There exist GUI wrappers around the Appium
server that can be downloaded.
• These come bundled with everything required
to run the Appium server, so you don’t need
to worry about Node.
• They also come with an Inspector, which
enables you to check out the hierarchy of your
app. This can come in handy when writing
tests.
33
34. Installation using the APP
To install:
• Download the latest version from Appium.io.
• Mount the disk image.
• Drag Appium.app to your Applications folder.
• Run it!!!
34
36. Install Dependencies
• Currently logging is based on idevicesyslog,
and port forwarding is based on iProxy, both
of which are part of libimobiledevice, so you
need to install it with Homebrew
brew install libimobiledevice
• In order to run the WebDriverAgent bootstrap
script you will need to install
the Carthage dependency manager
brew install carthage
36
37. Install Dependencies
• Installing deviceconsole
• An iOS system log trailer to debug problems
• Allows analyzing Crash Logs and Console output from
the device.
npm install deviceconsole
• Installing ios-deploy
iOS deploy is used to deploy your app to a
connected device
npm install -g ios-deploy
37
38. Installing dependencies using HEAD
• head URLs (activated by passing --HEAD) build
the development cutting edge. By passing
the --HEAD option allows installing software
directly from a branch of a version-control
repository.
npm install ios-deploy –HEAD
npm install deviceconsole –HEAD
38
39. Installing Xcode Command line tools
• To install Xcode command line tools run:
$ xcode-select --install
39
40. Selenium
Install following Selenium components
• Selenium Standalone Server
• Get selenium WebDriver language binding
library for Java from section 'Selenium Client
& WebDriver Language Bindings' present on
below link:
http://docs.seleniumhq.org/download/
40
41. Appium Clients
• There are client libraries (in Java, Ruby, Python,
PHP, JavaScript, and C#) which support Appium’s
extensions to the WebDriver protocol.
• When using Appium, you need to use these client
libraries instead of your regular WebDriver client.
Link:
https://search.maven.org/#search%7Cga%7C1%7Cg
%3Aio.appium%20a%3Ajava-client
41
42. Authorize use of iOS Simulator
• You need to authorize use of the iOS Simulator
by running the authorize-ios binary made
available through npm.
• Install the program by running
npm install -g authorize-ios
42
43. Authorize use of the iOS Simulator
• You can invoke the program using
sudo authorize-ios
• If you are running Appium.app, you can
authorize iOS through the GUI.
Note: You need to do this every time you install
a new version of Xcode.
43
44. What is Sudo?
• sudo (/ˈsuːduː/ or /ˈsuːdoʊ/) is a program for Unix-like computer
operating systems that allows users to run programs with the
security privileges of another user, by default the superuser.
• It originally stood for "superuser do" as the older versions
of sudo were designed to run commands only as the superuser.
• Mac OS X: sudo command requires a non-blank admin password.
The sudo Terminal command can be used by administrators to
execute commands as a different user (for example, as root).
Alert: Be extra careful when using the sudo command. You will usually
have to enter your OS X system password and any mistakes can
permanently mess up your system for good. When in doubt, leave it
out!
44
45. Documentation
• Refer to the official documentation for
Appium versions 1.6 to see all the capabilities
you can choose from.
• There are some common capabilities and
then there are also separate Android only and
iOS only capabilities.
http://appium.io/slate/en/v1.6.0/?java#appium-
server-capabilities
45
47. Testing on real iOS Device
Why testing on real devices?
• There could be bugs that only show up when
your app is running on an actual iPhone or iOS
device.
• Testing your iOS app on a device is the best
way to gauge performance issues before you
go too far down the road.
47
48. Appium on real iOS devices
To get started on a real device, you will need the
following:
• An Apple Developer ID and a valid Developer Account
with a configured distribution certificate and
provisioning profile.
• An iPad or iPhone. Configure the device for
development and add the device to the member
center
• A signed .ipa file of your app, or the source code to
build one.
• A Mac with Xcode and the Xcode Command Line
Developer Tools.
48
49. Testing on real iOS Device
• Enroll in the Apple iOS Developer Program
– You’re going to need to enroll in the Apple iOS
developer program which is $99 a year.
– You’ll also need an actual iOS device.
• Your certificate is used to code sign the apps and they
uniquely identify you. In this step, you have to generate
and request two certificates: one for development and
one for distribution. You only need to do this once (not
for each app!).
• The development one is used for testing while the
distribution certificate is used to sign your app bundle
for distribution in the App Store once it’s ready.
49
50. Why Code Signing?
• Apple cares that it can identify who created the
app and that it can tell if the app has been
tampered with or not.
• These security measures are ensured by a
process known as code signing. When you create
an app package (binary) to put on a device, you
have to put your “digital signature” on it by code
signing it. Otherwise, Apple won’t let that app be
deployed on any device.
50
51. Running your test
• Once your device and app are configured, you
can run tests on that device by passing the -
U or --udid flag to the server or
the udid desired capability, and the bundle ID
(if the app is installed on the device) or the
path to the .ipa or .apk file via the --app flag or
the app desired capability.
51
53. XCUITest API vs UIAutomation API
• Unfortunately, the XCUITest API and the UIAutomation API
are not equivalent. In many cases (like with tap/click), the
behavior is identical. But some features that were available
in the UIAutomation backend are not yet available in the
new XCUITest backend. These known lacking features
include:
• Geolocation support (e.g., driver.location)
• Shaking the device
• Locking the device
• Rotating the device (note that this
is NOT device orientation, which is supported)
Appium has a plan to add these features back in future
releases of Appium.
53
54. Changes to make in existing script
Here are the changes that you will have to make to your
existing scripts to run automated tests on iOS10:
• Apple has given different class names to UI elements
and changed the application hierarchy. If you use
XPaths in your test, it will be necessary to rewrite them
to account for these changes.
• Apple has removed native support for XPath selectors,
making XPath significantly slower. When using
XCUITest, you can improve performance by using other
locators instead, such as accessibility id.
54
55. Avoid using Xpath locators
• Try not to use XPath locators unless there is
absolutely no other alternatives.
• In general, xpath locators might be times
slower, than other types of locators like
accessibility id, class name and predicate (up
to 100 times slower in some special cases).
• They are so slow, because xpath location is not
natively supported by Apple's XCTest
framework.
55
56. Migrating to XCUITest
• The Appium team has also published a doc
which might be helpful in helping users
migrate their tests:
https://github.com/appium/appium/blob/maste
r/docs/en/advanced-concepts/migrating-to-
xcuitest.md. (Released Oct 2016)
56