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)
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.
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.
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 itHere is a list of various desired capabilities which you could set at the Appium server level.
org.openqa.selenium.remote.DesiredCapabilities
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 |
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
Post a Comment