Desired capabilities are a set of keys and values sent to the Appium server to tell the server what kind of automation session should be started. There are various capabilities to modify the behavior of the server during the automation. For example, the platformName capability can be set to iOS to tell Appium an iOS session is needed, rather than an Android one. Or, the safariAllowPopups capability can be set to true to ensure that, during a Safari automation session, JavaScript is allowed to open up new windows.
An Appium test is very similar to a Selenium test: both use the same WebDriver, and DesiredCapabilities is used the same way.
Some desired capabilities can be used as environment variables. For example, the API key can be fetched from your local environment and doesn’t need to be replicated in the test script:
String bitbar_apiKey = env.get("BITBAR_APIKEY");
BitBar desired capabilities
Optional. In order to take advantage of BitBar infrastructure, devices, and testing capabilities, additional desired capabilities have been introduced. When running your Appium tests from the client side, some of these desired capabilities are mandatory while others are optional.
bitbar_username
Optional. The email registered at BitBar. You can use bitbar_apiKey instead. For example, username@domain.com.
bitbar_password
The password for your BitBar account. You can use bitbar_apiKey instead.
bitbar_target
Optional. The target test type. Use one of the following values: android and ios for native apps, selendroid when testing a hybrid app, and chrome and safari for web testing using the respective web browsers. selendroid is also needed for older Android devices with API strictly lower than 17. If bitbar_target is not set, the value of the platformName Appium capability is used.
Possible values: android, ios, selendroid, chrome, safari, xcuitest.
bitbar_project
Optional. The project name that will be displayed on the Web UI. If none is provided, the Cloud sets a Project X name to your run. For example, Appium iOS Project.
bitbar_description
Optional. Project description. For example, My first Appium project at BitBar Testing Cloud.
bitbar_testrun
Optional. The name given to each Test Run under a Project. If no run name was given, the Cloud gives a Test run name to the run. For example, Test Run 1.
bitbar_device
Required. The device name that uniquely identifies a device on BitBar. Alternatively, you can use a script to query for devices with particular properties (for example, with a python example). For example, iPhone 5c 7.0.4 A1532.
bitbar_app
Required when not using the browserName capability for browser automation. Specifies the Application file (.app/.apk) to be installed on the device. The App can be given as a public URL or as the file ID of the file in BitBar. Upload an application either through the UI or using the command line (handling files over CLI). For example:
-
http://www.example.com/MyApp.ipa -
126948355 -
latestNote: This option will use the latest apk/ipa used during the previous test run in the selected project.
bitbar_locale
Optional. The device language, identified by the java.util.locale Locale ID. Default value: EN. For example, fi_FI.
bitbar_testTimeout
Optional. The timeout for the whole test execution (in seconds). It’s configurable only if you have an active plan or subscription. For example, 1200. Default value: 600. Java: capabilities.SetCapability(“bitbar_testTimeout”, 1200);.
bitbar_apiKey
Required. You can use the API key for authentication instead of the user name and password. This is available in the My Accounts view. For example, e4f86ac5b94e39810f33ad4ab71850a6.
bitbar_testrunId
Optional. Applies only to Private Cloud and Enterprise. You can add a new Appium run as a new device run to an existing test run by providing a test run ID.
 |
A new test run is created if there’s already a run for a similar device. |
bitbar_multiSessionWait
Optional. Defines the duration in seconds (max. 60) the broker should wait for a new Appium session after the last call to driver.quit(). This capability allows users to call driver.quit() inside of their tests and start a new Appium test using the same broker session and device. Default value: 0.
bitbar_findDevice
Optional. Applies to BitBar Public Cloud, BitBar Private Cloud, and BitBar Enterprise. This can be used to turn off the Appium client’s feature of finding a close match to the requested device. This allows the requested device name not to be a perfect match but the Appium client will search for a similar device. Default value: true.
bitbar_appiumVersion
Optional. Applies to BitBar Public Cloud, BitBar Private Cloud, and BitBar Enterprise. Allows the user to connect to an older version of the Appium server if this is required.
|
Currently, iOS supports only the latest Appium version. If you need to use older versions, please contact our support. |
Default value: the latest available Appium version.
bitbar_frameworkId
Optional. Applies to BitBar Public Cloud, BitBar Private Cloud, and BitBar Enterprise. Allows users to use a non-default testing framework. This is especially interesting for Private Cloud users that have different framework setups for different projects. Default value: the default framework ID. For example, 42.
bundleId
Required for all iOS test runs. Bundle identifier is a unique string identifier that is assigned to an iOS app and is used to distinguish it from other apps on the device. It is composed of a reverse-domain name string followed by the app's name, for example, com.mycompany.myapp.
Appium desired capabilities
See the Appium desired capabilities documentation for the complete list of capabilities available for Appium.