Chapter-3: Understanding the Desired Capabilities

Chapter-3: Understanding the Desired Capabilities

In the previous chapter you were briefly introduced to Desired Capabilities. This is a core capability of Appium. In this chapter we will take a deep dive into this feature.

Desired Capabilities help us to configure the Appium server and provide the criteria which we wish to use for running our automation script. For example, we can request the environment (emulator or real-device), which version of the operating system to run the test on, and more. Desired Capabilities are key/value pairs encoded in JSON format and are sent to the Appium Server by the Appium client when a new automation session is requested.

Figure 1 - Appium Architecture
Figure-1:Appium Architecture.

DesiredCapabilities is a predefined library and in order to use it you need to import:

Org.openqa.selenium.remote.DesiredCapabilities

As Appium supports both Android and iOS, There are separate capabilities for both. However most of the capabilities remain common to both platforms.

Android:

{

 "platformName": "Android",

 "platformVersion": "8.0",

 "app": "/Users/username/Downloads/sample.apk",

 "deviceName": "c4e3f3cda"

 "automationName": "UiAutomator2"

}

iOS:

{

 "platformName": "iOS",

 "platformVersion": "11.4.1",

 "app": "/path/to/.ipa/file",

 "deviceName": "John’s iPhone",

 "udid": "bea36e2b0262ae4b77bd3463bd462922ee935d24"

 "automationName": "XCUITest"

}

The above is the JSON representation. To use this in code you can define the Desired Capabilities (for Android) as below:

DesiredCapabilities dc = new DesiredCapabilities();

dc.setCapability("platformName", "Android");

dc.setCapability("platformVersion", "8.0");

dc.setCapability("app", "/Users/test/Downloads/FirstAutomationTest/src/test/resources/DemoApp.apk");

dc.setCapability("deviceName", "c4e3f3cd");

dc.setCapability("automationName", "UiAutomator2");

In the above code snippet instead of defining Capability Name in a String you can use the Appium predefined interfaces such as MobileCapabilityType, IOSMobileCapabilityType and AndroidMobileCapabilityType to get Capability Names, so the above code snippet can be written in a better way:

DesiredCapabilities dc = new DesiredCapabilities();

dc.setCapability(MobileCapabilityType.PLATFORM_NAME, "Android");

dc.setCapability(MobileCapabilityType.PLATFORM_VERSION, "8.0");

dc.setCapability(MobileCapabilityType.APP, "/Users/test/Downloads/FirstAutomationTest/src/test/resources/DemoApp.apk");

dc.setCapability(MobileCapabilityType.DEVICE_NAME, "c4e3f3cd");

dc.setCapability(MobileCapabilityType.AUTOMATION_NAME, "UiAutomator2");

Desired capabilities for iOS and Android

We have many desired capabilities at our disposal depending on what we are trying to accomplish. However, there are specific capabilities we need to set based on what we are trying to test:

  • Mobile Web Android.
  • Mobile Web iOS.
  • Mobile Native Android.
  • Mobile Native iOS.

 

Mobile web - Android

If you want to automate the Chrome browser on Android device then you need to use these Desired Capabilities.

DesiredCapabilities dc = new DesiredCapabilities();

dc.setCapability(MobileCapabilityType.PLATFORM_NAME, "Android");

dc.setCapability(MobileCapabilityType.PLATFORM_VERSION, "OS version of your test device/simulator");

dc.setCapability(MobileCapabilityType.DEVICE_NAME, "Name of your test device");

// This capability will open the Chrome browser instead of Native app.

dc.setCapability(MobileCapabilityType.BROWSER_NAME, MobileBrowserType.CHROME);

dc.setCapability(MobileCapabilityType.AUTOMATION_NAME, "UiAutomator2");

Mobile web - iOS

DesiredCapabilities dc = new DesiredCapabilities();

dc.setCapability(MobileCapabilityType.PLATFORM_NAME, "iOS");

dc.setCapability(MobileCapabilityType.PLATFORM_VERSION, "OS version of your test device/simulator");

dc.setCapability(MobileCapabilityType.DEVICE_NAME, "Name of your test device");

// This capability will open the Safari browser instead of Native app.

dc.setCapability(MobileCapabilityType.BROWSER_NAME, MobileBrowserType.SAFARI);

dc.setCapability(MobileCapabilityType.AUTOMATION_NAME, "XCUITest");

// If you are using Real iPhone device then you need to specify "udid" of device.

dc.setCapability("udid", "UDID of your test device");

Mobile native - Android

DesiredCapabilities dc = new DesiredCapabilities();

dc.setCapability(MobileCapabilityType.PLATFORM_NAME, "Android");

dc.setCapability(MobileCapabilityType.PLATFORM_VERSION, "OS version of your test device/simulator");

dc.setCapability(MobileCapabilityType.APP, "/path/to/.apk/file");

dc.setCapability(MobileCapabilityType.DEVICE_NAME, "Name of your test device");

dc.setCapability(MobileCapabilityType.AUTOMATION_NAME, "UiAutomator2");

Mobile native - iOS

DesiredCapabilities dc = new DesiredCapabilities();

dc.setCapability(MobileCapabilityType.PLATFORM_NAME, "iOS");

dc.setCapability(MobileCapabilityType.PLATFORM_VERSION, "OS version of your test device/simulator");

dc.setCapability(MobileCapabilityType.APP, "/path/to/.app or .ipa/file");

dc.setCapability(MobileCapabilityType.DEVICE_NAME, "Name of your test device");

dc.setCapability(MobileCapabilityType.AUTOMATION_NAME, "XCUITest");

List of all capabilities

There are many, many capabilities that Appium supports. We can categorize the Capabilities into 3 parts:

  • General Capabilities.
  • iOS Capabilities.
  • Android Capabilities.

While you clearly don’t need to memorize all of these, we do suggest you spend the time to familiarize yourself with these capabilities. As you use Appium more and more and continue to consult this list, you will eventually have a good sense of what capabilities are available to you.

General capabilities

 

Capability Description Values

automationName

Which automation engine to use

Appium (default) or Selendroid or UiAutomator2 or Espresso for Android or XCUITest for iOS

platformName

Which mobile OS platform to use

iOS, Android, or Firefox OS

platformVersion

Mobile OS version

e.g., 7.1, 4.4

deviceName

The kind of mobile device or emulator to use

iPhone Simulator, iPad Simulator, iPhone Retina 4-inch, Android Emulator, Galaxy S4, etc.... On iOS, this should be one of the valid devices returned by instruments with instruments -s devices. On Android this capability is currently ignored, though it remains required.

app

The absolute local path or remote http URL to a .ipa file (IOS), .app folder (IOS Simulator) or .apk file (Android), or a .zip file containing one of these (for .app, the .app folder must be the root of the zip file). Appium will attempt to install this app binary on the appropriate device first. Note that this capability is not required for Android if you specify appPackage and appActivity capabilities (see below). Incompatible with browserName.

/abs/path/to/my.apk or http://myapp.com/app.ipa

browserName

Name of mobile web browser to automate. Should be an empty string if automating an app instead.

'Safari' for iOS and 'Chrome', 'Chromium', or 'Browser' for Android

newCommandTimeout

How long (in seconds) Appium will wait for a new command from the client before assuming the client quit and ending the session

e.g. 60

language

(Sim/Emu-only) Language to set for the simulator / emulator. On Android, available only on API levels 22 and below

e.g. fr

locale

(Sim/Emu-only) Locale to set for the simulator / emulator.

e.g. fr_CA

udid

Unique device identifier of the connected physical device

e.g. 1ae203187fc012g

orientation

(Sim/Emu-only) start in a certain orientation

LANDSCAPE or PORTRAIT

autoWebview

Move directly into Webview context. Default false

true, false

noReset

Don't reset app state before this session. See here for more details

true, false

fullReset

Perform a complete reset. See here for more details

true, false

eventTimings

Enable or disable the reporting of the timings for various Appium-internal events (e.g., the start and end of each command, etc.). Defaults to false. To enable, use true. The timings are then reported as events property on response to querying the current session. See the event timing docs for the the structure of this response.

e.g., true

enablePerformanceLogging

(Web and webview only) Enable Chromedriver's (on Android) or Safari's (on iOS) performance logging (default false)

true, false

printPageSourceOnFindFailure

When a find operation fails, print the current page source. Defaults to false.

e.g., true

 

Android capabilities

These Capabilities are available only on Android-based drivers (like UiAutomator2 for example).

Capability Description Values
appActivity Activity name for the Android activity you want to launch from your package. This often needs to be preceded by a . (e.g., .MainActivity instead of MainActivity). By default this capability is received from the package manifest (action: android.intent.action.MAIN , category: android.intent.category.LAUNCHER) MainActivity, .Settings
appPackage Java package of the Android app you want to run. By default this capability is received from the package manifest (@package attribute value) com.example.android.myApp, com.android.settings
appWaitActivity Activity name/names, comma separated, for the Android activity you want to wait for. By default the value of this capability is the same as for appActivity. You must set it to the very first focused application activity name in case it is different from the one which is set as appActivity if your capability has appActivity and appPackage. SplashActivity, SplashActivity,OtherActivity, *, *.SplashActivity
appWaitPackage Java package of the Android

app you want to wait for. By default the value of this capability is the same as for appActivity

com.example.android.myApp, com.android.settings
appWaitDuration Timeout in milliseconds used to wait for the appWaitActivity to launch (default 20000) 30000
deviceReadyTimeout Timeout in seconds while waiting for device to become ready 5
androidCoverage Fully qualified instrumentation class. Passed to -w in adb shell am instrument -e coverage true -w com.my.Pkg/com.my.Pkg

.instrumentation.MyInstrumentation

androidCoverageEndIntent A broadcast action implemented by yourself which is used to dump coverage into file system. Passed to -a in adb shell am broadcast -a com.example.pkg.END_EMMA
androidDeviceReadyTimeout Timeout in seconds used to wait for a device to become ready after booting e.g., 30
androidInstallTimeout Timeout in milliseconds used to wait for an apk to install to the device. Defaults to 90000 e.g., 90000
androidInstallPath The name of the directory on the device in which the apk will be push before install. Defaults to /data/local/tmp e.g. /sdcard/Downloads/
adbPort Port used to connect to the ADB server (default 5037) 5037
systemPort systemPort used to connect to appium-uiautomator2-server, default is 8200 in general and selects one port from 8200 to 8299. When you run tests in parallel, you must adjust the port to avoid conflicts. Read Parallel Testing Setup Guide for more details. e.g., 8201
remoteAdbHost Optional remote ADB server host e.g.: 192.168.0.101
androidDeviceSocket Devtools socket name. Needed only when tested app is a Chromium embedding browser. The socket is open by the browser and Chromedriver connects to it as a devtools client. e.g., chrome_devtools_remote
avd Name of avd to launch e.g., api19
avdLaunchTimeout How long to wait in milliseconds for an avd to launch and connect to ADB (default 120000) 300000
avdReadyTimeout How long to wait in milliseconds for an avd to finish its boot animations (default 120000) 300000
avdArgs Additional emulator arguments used when launching an avd e.g., -netfast
useKeystore Use a custom keystore to sign apks, default false true or false
keystorePath Path to custom keystore, default ~/.android/debug.keystore e.g., /path/to.keystore
keystorePassword Password for custom keystore e.g., foo
keyAlias Alias for key e.g., androiddebugkey
keyPassword Password for key e.g., foo
chromedriverExecutable The absolute local path to webdriver executable (if Chromium embedder provides its own webdriver, it should be used instead of original chromedriver bundled with Appium) /abs/path/to/webdriver
chromedriverExecutableDir The absolute path to a directory to look for Chromedriver executables in, for automatic discovery of compatible Chromedrivers. Ignored if chromedriverUseSystemExecutableis true /abs/path/to/chromedriver
/directory
chromedriver
ChromeMappingFile
The absolute path to a file which maps Chromedriver versions to the minimum Chrome that it supports. Ignored if chromedriverUseSystemExecutableis true /abs/path/to/mapping.json
chromedriverUse
SystemExecutable
If true, bypasses automatic Chromedriver configuration and uses the version that comes downloaded with Appium. Ignored if chromedriverExecutable is set. Defaults to false e.g., true
autoWebviewTimeout Amount of time to wait for Webview context to become active, in ms. Defaults to 2000 e.g. 4
intentAction Intent action which will be used to start activity (default android.intent.action.MAIN) e.g.android.intent.action.MAIN, android.intent.action.VIEW
intentCategory Intent category which will be used to start activity (default android.intent.category.LAUNCHER) e.g. android.intent.category.
LAUNCHER, android
.intent.category.
APP_CONTACTS
intentFlags Flags that will be used to start activity (default 0x10200000) e.g. 0x10200000
optionalIntentArguments Additional intent arguments that will be used to start activity. See Intent arguments e.g. --esn <EXTRA_KEY>, --ez <EXTRA_KEY> <EXTRA_BOOLEAN_VALUE>, etc.
dontStopAppOnReset Doesn't stop the process of the app under test, before starting the app using adb. If the app under test is created by another anchor app, setting this false, allows the process of the anchor app to be still alive, during the start of the test app using adb. In other words, with dontStopAppOnReset set to true, we will not include the -Sflag in the adb shell am start call. With this capability omitted or set to false, we include the -S flag. Default false true or false
unicodeKeyboard Enable Unicode input, default false true or false
resetKeyboard Reset keyboard to its original state, after running Unicode tests with unicodeKeyboard capability. Ignored if used alone. Default false true or false
noSign Skip checking and signing of app with debug keys, will work only with UiAutomator and not with selendroid, default false true or false
ignoreUnimportantViews Calls the setCompressedLayoutHierarchy()uiautomator function. This capability can speed up test execution, since Accessibility commands will run faster ignoring some elements. The ignored elements will not be findable, which is why this capability has also been implemented as a toggle-able setting as well as a capability. Defaults to false true or false
disableAndroidWatchers Disables android watchers that watch for application not responding and application crash, this will reduce cpu usage on android device/emulator. This capability will work only with UiAutomator and not with selendroid, default false true or false
chromeOptions Allows passing chromeOptions capability for ChromeDriver. For more information see chromeOptions chromeOptions:
{args: ['--disable-popup-blocking']}
recreateChromeDriverSessions Kill ChromeDriver session when moving to a non-ChromeDriver webview. Defaults to false true or false
nativeWebScreenshot In a web context, use native (adb) method for taking a screenshot, rather than proxying to ChromeDriver. Defaults to false true or false
androidScreenshotPath The name of the directory on the device in which the screenshot will be put. Defaults to /data/local/tmp e.g. /sdcard/screenshots/
autoGrantPermissions Have Appium automatically determine which permissions your app requires and grant them to the app on install. Defaults to false. If noReset is true, this capability doesn't work. true or false
networkSpeed Set the network speed emulation. Specify the maximum network upload and download speeds. Defaults to full ['full','gsm', 'edge', 'hscsd', 'gprs', 'umts', 'hsdpa', 'lte', 'evdo']Check -netspeed option more info about speed emulation for avds
gpsEnabled Toggle gps location provider for emulators before starting the session. By default the emulator will have this option enabled or not according to how it has been provisioned. true or false
isHeadless Set this capability to true to run the Emulator headless when device display is not needed to be visible. false is the default value. isHeadless is also support for iOS, check XCUITest-specific capabilities. e.g., true
uiautomator2Server
LaunchTimeout
Timeout in milliseconds used to wait for an uiAutomator2 server to launch. Defaults to 20000 e.g., 20000
uiautomator2Server
InstallTimeout
Timeout in milliseconds used to wait for an uiAutomator2 server to be installed. Defaults to 20000 e.g., 20000
otherApps App or list of apps (as a JSON array) to install prior to running tests e.g., "/path/to/app.apk", https://www.example.com/url/to/app.apk, ["/path/to/app-a.apk", "/path/to/app-b.apk"]

 

iOS capabilities

These Capabilities are available only on the XCUITest Driver and the deprecated UIAutomation Driver.

Capability Description Values
calendarFormat (Sim-only) Calendar format to set for the iOS Simulator e.g. gregorian
bundleId Bundle ID of the app under test. Useful for starting an app on a real device or for using other caps which require the bundle ID during test startup. To run a test on a real device using the bundle ID, you may omit the 'app' capability, but you must provide 'udid'. e.g. io.appium.TestApp
udid Unique device identifier of the connected physical device e.g. 1ae203187fc012g
launchTimeout Amount of time in ms to wait for instruments before assuming it hung and failing the session e.g. 20000
locationServicesEnabled (Sim-only) Force location services to be either on or off. Default is to keep current sim setting. true or false
locationServicesAuthorized (Sim-only) Set location services to be authorized or not authorized for app via plist, so that location services alert doesn't pop up. Default is to keep current sim setting. Note that if you use this setting you MUST also use the bundleId capability to send in your app's bundle ID. true or false
autoAcceptAlerts Accept all iOS alerts automatically if they pop up. This includes privacy access permission alerts (e.g., location, contacts, photos). Default is false. Does not work on XCUITest-based tests. true or false
autoDismissAlerts Dismiss all iOS alerts automatically if they pop up. This includes privacy access permission alerts (e.g., location, contacts, photos). Default is false. Does not work on XCUITest-based tests. true or false
nativeInstrumentsLib Use native intruments lib (ie disable instruments-without-delay). true or false
nativeWebTap (Sim-only) Enable "real", non-javascript-based web taps in Safari. Default: false. Warning: depending on viewport size/ratio this might not accurately tap an element true or false
safariInitialUrl (Sim-only) (>= 8.1) Initial safari url, default is a local welcome page e.g. https://www.github.com
safariAllowPopups (Sim-only) Allow javascript to open new windows in Safari. Default keeps current sim setting true or false
safariIgnoreFraudWarning (Sim-only) Prevent Safari from showing a fraudulent website warning. Default keeps current sim setting. true or false
safariOpenLinksInBackground (Sim-only) Whether Safari should allow links to open in new windows. Default keeps current sim setting. true or false
keepKeyChains (Sim-only) Whether to keep keychains (Library/Keychains) when appium session is started/finished true or false
localizableStringsDir Where to look for localizable strings. Default en.lproj en.lproj
processArguments Arguments to pass to the AUT using instruments e.g., -myflag
interKeyDelay The delay, in ms, between keystrokes sent to an element when typing. e.g., 100
showIOSLog Whether to show any logs captured from a device in the appium logs. Default false true or false
sendKeyStrategy strategy to use to type test into a test field. Simulator default: oneByOne. Real device default: grouped oneByOne, grouped or setValue
screenshotWaitTimeout Max timeout in sec to wait for a screenshot to be generated. default: 10 e.g., 5
waitForAppScript The ios automation script used to determined if the app has been launched, by default the system wait for the page source not to be empty. The result must be a boolean e.g. true;, target.elements().length > 0;, $.delay(5000); true;
webviewConnectRetries Number of times to send connection message to remote debugger, to get webview. Default: 8 e.g., 12
appName The display name of the application under test. Used to automate backgrounding the app in iOS 9+. e.g., UICatalog
customSSLCert (Sim only) Add an SSL certificate to IOS Simulator. e.g.

-----BEGIN CERTIFICATE-----MIIFWjCCBEKg...

-----END CERTIFICATE-----

webkitResponseTimeout (Real device only) Set the time, in ms, to wait for a response from WebKit in a Safari session. Defaults to 5000 e.g., 10000
remoteDebugProxy (Sim only, <= 11.2) If set, Appium sends and receives remote debugging messages through a proxy on either the local port (Sim only, <= 11.2) or a proxy on this unix socket (Sim only >= 11.3) instead of communicating with the iOS remote debugger directly. e.g. 12000 or "/tmp/my.proxy.socket"

 

Important capabilities

Reset strategies

In Mobile Application Automation, most of the execution time is spent on Application installation. Sometimes you do not want to reinstall the application (like between tests) so Appium has provided 2 capabilities named noReset and fullReset which provides control over application installation and you can leverage the right combination of the two flags.

noReset fullReset Result on iOS Result on Android
true true Error: The 'noReset' and 'fullReset' capabilities are mutually exclusive and should not both be set to true
true false Do not destroy or shut down simulator after test. Start tests running on whichever simulator is running, or device is plugged in. Do not stop app, do not clear app data, and do not uninstall apk.
false true Uninstall app after real device test, destroy Simulator after sim test. Stop app, clear app data and uninstall apk after test.
false false Shut down simulator after test. Do not destroy simulator. Do not uninstall app from real device. Stop and clear app data after test. Do not uninstall apk


NOTE: You can know more about Appium Capabilities on Official Appium Docs periodically: http://appium.io/docs/en/writing-running-appium/caps/

The following additional capabilities are reprinted with permission from Jonathan Lipps, Founding Principal of Cloud Grey, a mobile testing services company. Refer to footnote for the source link.

Android-specific capabilities

disableAndroidWatchers:
The only way to check for toast messages on Android is for the Appium UiAutomator2 driver to run a loop constantly checking the state of the device. Running a loop like this takes up valuable CPU cycles and has been observed to make scrolling less consistent, for example. If you don't need the features that require the watcher loop (like toast verification), then set this cap to true to turn it off entirely and save your device some cycles.

autoGrantPermission:
Set to true to have Appium attempt to automatically determine your app permissions and grant them, for example to avoid system pop ups asking for permission later on in the test.

skipUnlock:
Appium doesn't assume that your device is unlocked, and it should be to successfully run tests. So it installs and runs a little helper app that tries to unlock the screen before a test. Sometimes this works, and sometimes this doesn't. But that's beside the point: either way, it takes time! If you know your screen is unlocked, because you're managing screen state with something other than Appium, tell Appium not to bother with this little startup routine and save yourself a second or three, by setting this cap to true.

appWaitPackage and appWaitActivity:
Android activities can be kind of funny. In many apps, the activity used to launch the app is not the same as the activity which is active when the user initially interacts with the application. Typically it's this latter activity you care about when you run an Appium test. You want to make sure that Appium doesn't consider the session started until this activity is active, regardless of what happened to the launch activity.

In this scenario, you need to tell Appium to wait for the correct activity, since the one it automatically retrieves from your app manifest will be the launch activity. You can use the appWaitPackage and appWaitActivity to tell Appium to consider a session started (and hence return control to your test code) only when the package and activity specified have become active. This can greatly help the stability of session start, because your test code can assume your app is on the activity expects when the session starts.

ignoreUnimportantViews:
Android has two modes for expressing its layout hierarchy: normal and "compressed". The compressed layout hierarchy is a subset of the hierarchy that the OS itself sees, restricted to elements which the OS thinks are more relevant for users, for example elements with accessibility information set on them. Because compressed mode generates a smaller XML file, and perhaps for other Android-internal reasons, it's often faster to get the hierarchy in compressed mode. If you're running into page source queries taking a very long time, you might try setting this cap to true.

Note that the XML returned in the different modes is ... different. Which means that XPath queries that worked in one mode will likely not work in the other. Make sure you don't change this back and forth if you rely on XPath!

iOS-specific capabilities

usePrebuiltWDA and derivedDataPath:
Typically, Appium uses xcodebuild under the hood to both build WebDriverAgent and kick off the XCUITest process that powers the test session. If you have a prebuilt WebDriverAgent binary and would like to save some time on startup, set the usePrebuiltWDA cap to true. This cap could be used in conjunction with derivedDataPath, which is the path to the derived data folder where your WebDriverAgent binary is dumped by Xcode.

useJSONSource:
For large applications, it can be faster for Appium to deal with the app hierarchy internally as JSON, rather than XML, and convert it to XML at the "edge", so to speak---in the Appium driver itself, rather than lower in the stack. Basically, give this a try if getting the iOS app source is taking forever.

iosInstallPause:
Sometimes, large iOS applications can take a while to launch, but there's no way for Appium to automatically detect when an app is ready for use or not. If you have such an app, set this cap to the number of milliseconds you'd like Appium to wait after WebDriverAgent thinks the app is online, before Appium hands back control to your test script. It might help make session startup a bit more stable.

maxTypingFrequency:
If you notice errors during typing, for example the wrong keys being pressed or visual oddities you notice while watching a test, try slowing the typing down. Set this cap to an integer and play around with the value until things work. Lower is slower, higher is faster! The default is 60.

realDeviceScreenshotter:
Appium has its own methods for capturing screenshots from simulators and devices, but especially on real devices this can be slow and/or flaky. If you're a fan of the libimobiledevice suite and happen to have idevicescreenshot on your system, you can use this cap to let Appium know you'd prefer to retrieve the screenshot via a call to that binary instead of using its own internal methods. To make it happen, simply set this cap to the string "idevicescreenshot"!

simpleIsVisibleCheck:
Element visibility checks in XCUITest are fraught with flakiness and complexity. By default, the visibility checks available don't always do a great job. Appium implemented another type of visibility check inside of WebDriverAgent that might be more reliable for your app, though it comes with the downside that the checks could take longer for some apps. As with many things in life, we sometimes have to make trade-offs between speed and reliability.

NOTE: You can learn more about Android & iOS specific Capabilities on Jonathan Lipps’ (Appium project lead and architect) blog: https://appiumpro.com/editions/24

We suggest reviewing these capabilities and familiarize yourself with them. It isn’t necessary to memorize them, but as you get more sophisticated testing needs it will be good to keep coming back here to see which one will do the trick. We’ll be using various forms of these capabilities throughout the rest of the book so you will start getting more familiar with them as we work through more examples.

Tags:
,
No Comments

Post A Comment