This is the 4th in a series of place that discuss using Appium with Sauce Labs.

Chapter 1 coveredLanguage Bindings;Chapter 2 saucerTouch Actions, and Chapter 3 screenTesting Hybrid Apps & amp; Mobile Web.

Appium, by and large, supports the desired capabilities you ’ re familiar with from Selenium. However, given that it besides exposes mobile-specific functionality, we have some mobile-specific craved capabilities. We even have capabilities that are specific to one mobile platform: iOS or Android. For the full lean of potentiality Appium supports, delight see thecapabilities doc.

Environment-specifying Capabilities

The main differences you ’ ll recognize will have to do with selecting which type of mobile environment you want to automate. Appium has adopted the “ Selenium 4″ mode of session capabilities, which means that, rather of capabilities like this, for example:

[code language= ” javascript ”]
{
browserName: ‘ safari ’,
version: ‘ 6.0 ’
}
[/code]

You would delineate the following, for Mobile Safari on iOS 7.1:

[code language= ” javascript ”]
{
platformName: ‘ iOS ’,
platformVersion: ‘ 7.1 ’,
deviceName: ‘ iPhone Simulator ’,
browserName: ‘ safari ’
}
[/code]

The new potentialityplatformName, platformVersion, and deviceNameare _required_ for every session. Valid platforms areiOS and Android.

To automatize a native or hybrid app instead of a mobile browser, you overleap thebrowserNamepotentiality and include theappcapability, which is a fully-resolved local path or URL to your coating (.app, .ipa, or .apk). For model:

[code language= ” javascript ”]
{
platformName: ‘ Android ’,
platformVersion: ‘ 5.0 ’,
deviceName: ‘ Android Emulator ’,
app: ‘ /path/to/my/android_app.apk ’
}
[/code]

Sometimes we might want to run an Android examination on an older device, and so we need to use Appium ’ s built-in Selendroid support for aged devices. To delineate that you want to use the Selendroid backend, keep everything else the same, but specify theautomationNamepotentiality, as follows:

[codification language= ” javascript ”]
{
automationName: ‘ Selendroid ’,
platformName: ‘ Android ’,
platformVersion: ‘ 5.0 ’,
deviceName: ‘ Android Emulator ’,
app: ‘ /path/to/my/android_app.apk ’
}
[/code]

And of course, if you ’ re escape any tests on Sauce Labs, get sure to delimitate the variation of Appium you ’ d like to use with theappiumVersioncapability:

[code language= ” javascript ”]
{
platformName: ‘ Android ’,
platformVersion: ‘ 5.0 ’,
deviceName: ‘ Android Emulator ’,
browserName: ‘ Browser ’,
appiumVersion: ‘ 1.3.4 ’
}
[/code]

General Capabilities

Here are some other cross-platform capability that involve how your session will run.

Capability

Description

autoLaunch

Whether to hold Appium install and launch your app.

language

Change the default speech on the device. (Emulator only)

locale

Change the default locale on the device. (Emulator exclusively)

udid

Unique device identifier for a connected physical gimmick. Helps Appium determine the gimmick on which to execute tests.

orientation

Change the starting orientation of the device. (Emulator but)

autoWebview

When your test starts, have Appium move straightaway into Webview circumstance.

noReset

Don ’ t reset app state before this session.

fullReset

(iOS) Delete the entire simulator folder. (Android) Reset app province by uninstalling app instead of clearing app data. On Android, this will also remove the app after the session is complete.

Android-only Capabilities

Managing Packages and Activities

Android application executing sometimes involve multiple packages and activities. For model, your coating might have a splash screen or users might launch one action from another. Appium crackappWaitActivity and appWaitPackageto allow you to essay these more complex scenarios. If you want to wait for activity A to be visible before launching activity B, as you would in the case of a splash screen, your capableness might seem like this:

SUSA automates exploratory testing with persona-driven behavior, catching bugs that scripted automation misses.

[code language= ” javascript ”]
{
automationName: ‘ Selendroid ’,
platformName: ‘ Android ’,
platformVersion: ‘ 5.0 ’,
deviceName: ‘ Android Emulator ’,
app: ‘ /path/to/my/android_app.apk ’,
// appActivity/Package are autodiscovered, so no motivation to specify
appWaitActivity: ‘ .SplashActivity ’,
appWaitPackage: ‘ com.corp.foo ’
}
[/code]

If you ’ re would like to run a test suite that is Instrumentation-compatible, you can specify it using theandroidCoveragecapability:

[code language= ” javascript ”]
{
…
androidCoverage: ‘ my.fq.class.name ’
}
[/code]

Signing Packages

Running tests using Android ’ s Instrumentation (which is what powers the Selendroid mechanisation backend) requires that binaries curb tests be signed with the same certificate as the apk. Appium normally uses a self-signed certificate under the hood to take caution of this, but you can overthrow Appium ’ s default behavior by apply capabilities to specify the keystore of your choice.

[code language= ” javascript ”]
{
…
useKeystore: true,
keystorePath: ‘ /my/keystore ’,
keyAlias: ‘ androiddebugkey ’,
keystorePassword: ‘ foo ’,
keyPassword: ‘ bar ’,
noSign: false // alone works with UiAutomator; defaults to false
}
[/code]

Chrome and Chromedriver

Appium on Android uses Chromedriver for examine peregrine browse and hybrid coating. To facilitate these tests, Appium offers capabilities that expose many of Chromedrivers lineament. If you ’ ve pen a intercrossed application and would like to capture Chromedriver ’ s performance logging, setenablePerformanceLogging to true. If you ’ re using a Chromium embedded browser, you can specify which socket port Chromedriver should use to connect as a devtools client viaandroidDeviceSocket. Appium also allows you to overturn the Chromedriver version by supplying thechromedriverExecutablecapability. Finally, you can hold the amount of time that Chromedriver, and hence Appium, waits for a webview to become active by using theautoWebviewTimeoutcapability.

[code language= ” javascript ”]
{
…
enablePermanceLogging: true,
androidDeviceSocket: ‘ crazy_fast_socket ’,
chromedriverExecutable: ‘ /my/bleeding/edge/build ’,
autoWebviewTimeout: 2000 // this is the default, in ms
}
[/code]

Android Intents

Many Android applications are launched by intent messages. To enable these scenario in a examination environment, Appium provides a grouping of capableness that permit you launch your application by intent. The intent options are straightforward and map intimately to ADB ’ sintentbid line interface.

[code language= ” javascript ”]
{
…
intentAction: ‘ android.intent.action.MAIN ’,
intentCategory: ‘ android.intent.category.APP_CONTACTS ’,
intentFlags: ‘ 0x10200000 ’, // Bit flag hex value supplied as string
optionalIntentArguments: ‘ –ez
& amp; amp; amp; lt; EXTRA_KEY & amp; amp; amp; gt; & amp; amp; amp; lt; EXTRA_BOOLEAN_VALUE & amp; amp; amp; gt; ’ // ADB
command line arguments
}
[/code]

Miscellany

Appium likewise provide a few former pieces of capability magic to help power your tests.stopAppOnResetensures that your app is entirely stopped between sessions, and is on by default. At the start of each session, Appium stops the coating process using ADB, and then resume it. This behavior may not be desireable in cases where a control instance launches child processes. Set this capableness tofalsewhen you want to keep the controlling process alive between Appium sessions.

Many applications swear on unicode characters. Unfortunately, Android ’ s UI Automator framework silently uncase everything that is not in the ASCII range. So sending, say,sūkṣma, merely sendsskmato the application under trial. By settingunicodeKeyboard to true, Appium encode strings using modified UTF-7, so decodes it rearwards into the full character in the IME on the device. That prevents data loss when working with unicode strings. You can useresetKeyboardto ensure the keyboard is returned to its original province (i.e., returned to the keyboard that was combat-ready before we switched to the Unicode keyboard) after pass Unicode trial with theunicodeKeyboardcapability.

Finally, Appium provides theignoreUnimportantViewswhich calls thesetCompressedLayoutHierarchy ()UiAutomator function. This capability can speed up test executing, since Accessibility bidding will run faster, ignoring some elements. The unheeded elements will not be findable, which is why this capability has too been implemented as a toggle-able setting as well as a capacity.

[code language= ” javascript ”]
{
…
stopAppOnReset: true,
unicodeKeyboard: true,
resetKeyboard: true,
ignoreUnimportantViews: false
}
[/code]

iOS-only Capabilities

For iOS trial, there is a pretty large dispute between what we can check on an iOS simulator versus and iOS existent gimmick. This is because we can modify the several settings file that find the simulator behavior on the host machine, whereas we have no access to the minute of a existent device that determine the tantamount behavior. Thus the iOS section is divided into two: capableness that work everyplace and capabilities that work just on simulators.

General iOS Capabilities

Sometimes, we require to test against an app that is already installed on the simulator or device, and we don ’ t feature an .app or .ipa file locally. In that lawsuit, we can use thebundleIdcapability to narrate Appium to simply try to automatise the be app (of course it needs to be signed and valid for your gimmick):

[codification language= ” javascript ”]
{
bundleId: ‘ io.appium.TestApp ’
}
[/code]

When launching iOS tests, we use Apple ’ s Instruments binary. Instruments is unfortunately quite flakey and sometimes simply hangs on startup. The only thing we can do about that is time out and try again. You can fine-tune the timeout value (in msec) after remark how long it should conduct on your particular form for Instruments to launch the simulator successfully:

[codification language= ” javascript ”]
{
launchTimeout: 20000
}
[/code]

After Instruments launches a test session, Appium tries to make sure that it doesn ’ t let your examination code keep running until it knows your app has really launched. To determine this, it assure to see whether there are any elements in your app. For whatever reason, some apps have trouble reporting that there are any such elements, and so the session ne'er begins. In these cases, you can really customize the UIAutomation script we use to regulate the exam can proceed. For example, you might but tell Appium to wait 5 seconds and uphold, acquire the app is ready:

[code language= ” javascript ”]
{
waitForAppScript: “ $ .delay (5000); true; ”
}
[/code]

If you ’ re starting up a webview-based app, or a web test using Safari, Appium will attempt to institute a remote debugger session with the webview so that it can send it the necessary web mechanisation commands. Sometimes the connection isn ’ t established instantly and we have to retry. You can customize the number of times we retry before giving up. The default is 8.

[code language= ” javascript ”]
{
webviewConnectRetries: 12
}
[/code]

Sometimes your application or the operating system will drop up alerts during execution. If you don ’ t tending about handling these intentionally using the WebDriver alarm API, you can tell Appium to simply accept or discount any that it can, with these two capability (which are reciprocally exclusive, of course):

[code language= ” javascript ”]
{
autoAcceptAlerts: true,
// autoDismissAlerts: true
}
[/code]

If your app doesn ’ t have its focalize strings inen.lproj, you can specify just where Appium should look to find them (if you want to use the twine translation features):

[code language= ” javascript ”]
{
localizableStringsDir: “ de.lproj ”
}
[/code]

You can post command-line contention that your app can use to modify its behavior (say if you want to set a backend server reference, or something), using theprocessArguments cap:

[code language= ” javascript ”]
{
processArguments: “ -myflag ”
}
[/code]

Appium uses Apple ’ s UIAutomation ’ s typecast method to send keystroke to your app ’ s input fields. Sometimes we ’ ve observed that UIAutomation tries to do it too quickly and messes up (just like a real user, perhaps?). In some event, telling it to slow down helps. You can do this using theinterKeyDelaycapability (in milliseconds). This will cause extra time to be added between each keystroke. You can also change the strategy that Appium uses to post key entirely. There are three:oneByOne(each key is typed on its own),grouped(the default, where we mail the whole string to UIAutomation and let it figure it out), andsetValue, where we bypass the keyboard entirely and simply set the value of the field.

[code language= ” javascript ”]
{
interKeyDelay: 100, sendKeyStrategy: “ oneByOne ”
}
[/code]

It is sometimes convenient to debug what ’ s proceed on with your app by looking at your app ’ s log or the iOS simulator logarithm. You can extract these using the WebDriver log API in your test codification. You can also tell Appium to simply show you those logs, interleaved with its own log:

[codification language= ” javascript ”]
{
showIOSLog: true
}
[/code]

Sometimes, when seek to take a screenshot of an app with a lot of elements, it can take UIAutomation an extremely long time to generate the image. Sometimes it takes so long that it runs afoul of a timeout we hold set to make certain the screenshot command doesn ’ t hang forever. If you get timeouts expect for screenshots, you might want to bump the default (which is 10 seconds) to something higher. Note that this capability is in seconds!

[code language= ” javascript ”]
{
screenshotWaitTimeout: 20
}
[/code]

Simulator-only iOS Capabilities

The following capabilities will only work on the simulator, because they affect vary file on the system that host the simulator (which plainly won ’ t work on a real device).

First of all, we use a special tool telephoneinstruments-without-delayto work around a restriction of Apple ’ s UIAutomation, which tuck an artificial 1-second delay between _every_ automation bid. Usually there are no problems shoot this tool into the mechanisation engine, but if you want to be absolutely sure it ’ s not induce problem, you can always turn it off with:

[code language= ” javascript ”]
{
nativeInstrumentsLib: true
}
[/code]

You can set the calendar format the device uses:

[codification language= ” javascript ”]
{
calendarFormat: “ gregorian ”
}
[/code]

You can make sure that the device has position services enabled, and authorise for your app (which requires you to also tell us thebundleIdof your app). This forbid a foul authorization box from popping up in the centre of your test!

[code language= ” javascript ”]
{
locationServicesEnabled: true,
locationServicesAuthorized: true
}
[/code]

We also have a number of choice specifically to do with the Safari browser on an iOS simulator. You can ensure that native tap case (rather than JS event) are let triggered when you tap on web elements. You can set an initial url for Safari to call. You can tell Safari to allow new popup windows to be open by JavaScript. You can tell Safari to ignore its fraud warning (for example when visiting a site with a self-signed SSL security). You can besides instruct Safari to open new tie-in in the background instead than going to them mechanically. Some examples:

[code language= ” javascript ”]
{
nativeWebTap: true,
safariInitialUrl: “ http: //www.saucelabs.com ”,
safariAllowPopups: true,
safariIgnoreFraudWarning: true,
safariOpenLinksInBackground: true
}
[/code]

Finally, if you have a test setup where you rely on keychain data for a simulator, you can instruct Appium not to wipe this datum during its reset summons (where it would normally pan it for entire cleanliness):

[codification language= ” javascript ”]
{
keepKeyChains: true
}
[/code]

That wraps up this deeper dive into the wide and eldritch world of Appium ’ s capabilities! As advert earlier, keep an eye on theAppium docsfor any new ones that crop up. Also note that for good and practical understanding, some capabilities aren ’ t allow on Sauce Labs (for illustration, you won ’ t get an Android keystore on any of our freshly-created VMs, so it doesn ’ t make sense to say that it ’ s supported). Happy examination!