Appium Desired Capabilities

We have seen how to write Appium test for Android. Actually it’s NOT an actual test. If you see in that post, we run it as a JAVA APPLICATION. But before we write an actual test (or a meaningful test) we need to understand more about Appium desired capabilities.

Here we will explain what are Appium desired capabilities and why do we use them. But before we dive in the details, we will have to brush up our understanding about Appium architecture. You can read detailed post here.

We know that the Appium server does the following (in addition to other things that it does)
  • Receives connections from a client and creates a session

So what is a Session? (In terms of Appium automation)

Automation is always performed in the context of a session. When a client initiates a session with Appium server, it basically sends a POST/session request to the Appium server, with a JSON object called the ‘desired capabilities’. Appium server receives the connection and start up the automation session. Appium server responds with a session ID which is used for sending further commands.

Desired Capabilities

We have seen that automation with Appium begins with a session. Desired capabilities is a way of telling the Appium server what kind of session we are interested in. It is basically a hash (or a map) of keys & values. By using desired capabilities, we have more control on the server and modify the behavior of the server during automation.

Say we set the platformName capability as Android to tell Appium server that we are interested in an Android session, rather than iOS or Firefox.
NOTE: Desired capabilities are present in the below mentioned library. So you have to import and reference it in your project to use it
org.openqa.selenium.remote.DesiredCapabilities
Here is a list of various desired capabilities which you could set at the Appium server level.

Appium desired/server capabilities

Capability Description Values
automationName Which automation engine to use Appium (default) or Selendroid
platformName Which mobile OS platform to use iOS, Android, or FirefoxOS
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.
app The absolute local path or remote http URL to an .ipa or .apk file, or a .zip containing one of these. 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
autoLaunch Whether to have Appium install and launch the app automatically. Default true true, false
language (Sim/Emu-only) Language to set for the iOS Simulator e.g. fr
locale (Sim/Emu-only) Locale to set for the iOS Simulator 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. Default false true, false
fullReset (iOS) Delete the entire simulator folder. (Android) Reset app state by uninstalling app instead of clearing app data. On Android, this will also remove the app after the session is complete. Default false true, false
Credits : https://github.com/appium/appium/blob/master/docs/en/writing-running-appium/caps.md

This is it about Desired capabilities. In our coming posts, we will explain more about Desired capabilities specific to individual platform (Android and iOS)

If you liked the post, don’t forget to share and comment.

Comments

Popular posts from this blog

Writing first Android test using Appium

Sending keyboard input via ADB to your android device

Start & Stop Appium Server Programmatically using Java (MAC OSX)