Capabilities

Capabilities serve as a collection of keys and values that are transmitted to the Appium server to instruct it on the type of automation session to initiate. These capabilities offer diverse options to customize the server's behavior during automation. For instance, the platformName capability can be configured as iOS to indicate the need for an iOS session, as opposed to an Android one. Another example is the safariAllowPopups capability, which can be set to true to ensure that, during a Safari automation session, JavaScript can open new windows.

Appium tests closely resemble Selenium tests as both employ the same WebDriver, and Capabilities are utilized in a similar manner.

Furthermore, some capabilities can be utilized as environment variables, allowing you to fetch information like the API key directly from your local environment without the need for replication within the test script:

String bitbar_apiKey = env.get("BITBAR_APIKEY");

Custom BitBar Capabilities

To make the most of BitBar's infrastructure, devices, and testing capabilities, you can choose from additional capabilities. When you run your Appium tests from your end, you will find that some of these capabilities are necessary, while others are optional, giving you flexibility in your testing setup.

When testing with BitBar, you can customize your test runs by configuring custom capabilities organized within the bitbar:options object. This structured methodology, guided by adherence to W3C standards, enables you to establish customized settings that align with your testing requirements. This user-friendly structure ensures that you can tailor your tests to match your preferences.

Important

When using Appium version 1.x with Android, you can still use capabilities with the bitbar_ prefix individually without the requirement for aggregation within the bitbar:options object.

Table 4. Custom BitBar Capabilities

Capability

Value Type

Requirement

Description

apiKey

32-character alphanumeric string

Required

A security parameter that allows users to provide a unique authentication key or token necessary to access and interact with specific services or resources. This capability is crucial for secure access and authorization when working with external APIs, services, or protected data. The API key is available in the My Account view.

app

String

Integer

URL

Required

Specifies the application file (.apk or .app) 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 through the UI or the command line (handling files over CLI).

For example:

  • http://www.example.com/MyApp.ipa

  • 126948355

appiumVersion

String

Optional

Available in BitBar Public Cloud, BitBar Private Cloud, and BitBar Enterprise, empowers you to connect to an older version of the Appium server when the need arises. This ensures compatibility and flexibility in your testing setup.

Default value:

  • Android testing: 2.1

  • iOS testing: 2.0

Currently, we employ Appium 2.1 for Android testing and Appium 2.0 for iOS testing. Android also supports compatibility with various 1.x versions, providing viable alternatives.

biometricInstrumentation

Boolean

Optional

Allows users to configure and control biometric authentication settings during test scenarios. It provides means to enable or disable biometric authentication mechanisms, such as fingerprint or facial recognition, within the testing environment. This capability is particularly useful for testing apps or processes that involve biometric security features.

description

String

Optional

Enables you to provide a project description. For example, My first Appium project at BitBar.

device

String

Required

A distinctive identifier assigned to a device within BitBar. For example, iPhone 5c 7.0.4 A1532.

Alternatively, you can employ a script to search for devices based on specific properties, such as using a Python script as an example.

When you use the device capability together with deviceGroupId capability, the deviceGroupId takes precedence over the device capability.

deviceGroupId

Integer

Optional

The capability enables you to initiate a session with a device from a particular device group. For example, by indicating 4129 as the device group ID, you can ensure that your session starts with a device from that specific group. When you use the deviceGroupID capability along with device or findDevice capability, it takes precedence over them.

findDevice

Boolean

Optional

Determines how a system selects a device based on the provided name. When set to False, the system picks the device that matches the device name provided by the user. When set to True, the system selects the device based on lexical similarity to the user's input. For instance, if the user inputs iPhone, and there are devices named iPhone 11 and Samsung Galaxy, the system will likely choose the iPhone 11 because it's a closer match.

When you use the findDevice capability together with deviceGroupId capability, the deviceGroupId takes precedence over the findDevice capability.

frameworkId

Integer

Optional

Available in BitBar Public Cloud, BitBar Private Cloud, and BitBar Enterprise, provides users the flexibility to utilize a testing framework other than the default. This feature is particularly useful for Private Cloud users managing various projects with different framework configurations. The default value is set to the default framework ID (for example, 42), but this capability empowers users to tailor their testing setup to their specific project needs.

hookURL

URL

Optional

Defines the endpoint, for which the REST call will be executed after the test finishes.

idleTimeout

Integer

Optional

Designates the maximum duration of inactivity in seconds that a test session or automation framework will allow before automatically ending the session. This capability ensures efficient resource management by terminating idle sessions to free up resources for other tasks.

locale

String

Optional

The specific device language recognized by the Locale ID from the java.util.Locale class. It is used to configure and adapt the software to the language and regional preferences of the device's user. Default value: EN. For example, fi_FI.

multiSessionWait

Integer

Optional

Specifies the waiting duration in seconds (maximum 60) that the broker should wait for a new Appium session after the last call to driver.quit(). It provides the flexibility for users to invoke driver.quit() within their tests and initiate a new Appium test using the same broker session and device. The default value is set to 0, indicating immediate session transition if not otherwise configured.

project

String

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.

testName

String

Optional

Provides a user-defined name or identifier for a specific test within a testing environment. It allows testers to label and distinguish individual tests, making it easier to track and identify test results, especially in cases involving multiple tests or test suites.

testrun

String

Optional

The user-provided name for each test run within a project. The Cloud service assigns a default name if a name is not specified. For example, Test Run 1.

testTimeout

Integer

Optional

Defines the maximum duration, in seconds, that is allowed for the complete execution of a test. This timeout is adjustable for users with an active plan or subscription and helps ensure that test execution does not exceed a specified time limit.

Default value: 1800.

Java:

capabilities.SetCapability(
    "bitbar:options", 
    "{ 'testTimeout': '1800' }"
);


Standard Appium Capabilities

Refer to the Appium documentation to access the comprehensive list of available capabilities for Appium.

See Also

Publication date: