Appium 2.0 is almost here! Most of the foundational work has been done, and it has been in beta for some time now. If you haven't yet gotten the Appium 2.0 beta, you can read the Appium Pro article on installing Appium 2.0 and Appium 2.0 drivers to get started. Apart from the differences in how you make platform drivers available to your Appium install, there will be a number of other (mostly minor) breaking changes you need to be aware of once you start migrating your Appium 1.x scripts to Appium 2.x.
Read: Appium for Mobile Testing Infrastructure Setup
This article is the first in an ongoing series that will attempt to walk you through all these changes. The topic of discussion for this article is capability prefixes. "Capabilities" (formerly known as "desired capabilities") are the parameters you use to start an Appium session. They come in key/value pairs, (for example, platformName which allows you to specify which platform you want to automate, whether that is iOS, Android, Mac, Windows, etc...). Depending on your Appium client, you define capabilities in a variety of ways, either using capability enum objects or strings (as in Java) or by constructing a dict (as in Python).
Improve the Appium testing experience with HeadSpin. Learn more!
With Appium 2.0, the Appium server will enforce strict compability with the W3C WebDriver specification when it comes to Capabilities. The spec defines 9 official capabilities, many of which aren't used very frequently in Appium. The standard, official capabilities you're probably most familiar with could be the following:
- browserName
- platformName
- timeouts
(You can check out the others at the full list of official capabilities). When it comes to these standard capabilities, there are no breaking changes. But every other capability that you use with Appium tests (like deviceName or automationName or udid or app), are non-standard, from the perspective of the W3C spec. Going forward, Appium will reject these capabilities. So how can we keep sending Appium the information they are designed to send? Luckily, the W3C spec defines a way for non-standard capabilities to be accepted as valid. These capabilities must include a so-called "vendor prefix", which looks like a string ending in a colon. If we were to take the automationName capability as an example, we could turn it into a valid W3C capability by adding the appium: prefix:
With that background in mind, let's explore 3 different strategies for updating your tests to use these vendor prefixes appropriately, in order to avoid test failures during new session creation.
Check out: Tips for Speeding Up Your Remote Appium Sessions
Strategy #1: Manually update your capabilities
The first strategy is perhaps the best long-term strategy, but it involves the most work. Just go into your test code and update every instance of a non-official capability so that it has the appium: prefix!
Also read: Automating Mobile Web Browsers with Appium
Strategy #2: Use an updated Appium client
The Appium team is obviously aware that it's not pleasant to have to find and change every instance of a capability everywhere in a testsuite. So we've also been hard at work updating our client libraries so that, if the library detects a capability that would be invalid without an appium: vendor prefix, it will add that prefix automatically.
Also check: Attaching Appium Clients to Existing Sessions
What this means is that if you're simply using the most recent version of the Appium client library, the vendor prefix addition will happen for you under the hood. This is probably the simplest path forward at the present time, since it involves no work on your part other than updating your client, which is probably a good idea independently.
Remotely test and debug mobile, web, audio and video application on thousands of iOS devices around the world. Learn more.
Strategy #3: Use the relaxed-caps plugin
If you can't upgrade your client, or are using a Selenium client, don't give up hope! There's still a way to have Appium give you a bit of a break. While the Appium server itself will only accept valid W3C capabilities, I've written a plugin that adjusts Appium's behavior to be a little more lenient. When this plugin is active, it will accept the old-style, non-prefixed capabilities (well, secretly, what it does is just add them before you before the capabilities get to the new session creation function). The net result is that once again your tests can stay the same.
This plugin is called the relaxed-caps plugin, and it's one of the officially-supported Appium 2.0 plugins. You can see it, for example, if you run appium plugin list. And you can install it by running:
Then of course you'll need to activate it when you start your Appium server, to make sure you know what you're allowing in terms of plugins and session modification:
So, this concludes our first discussion of breaking changes in Appium 2.0. I hope that one of these 3 strategies will work well for you, and at least give you the time to update your capabilities to use the appropriate vendor prefix!
-1280X720-Final-2.jpg)
