Instructions for migrating Appium0.18.x to Appium1.x (useful frequently. I have answered a few questions ).

Instructions for migrating Appium0.18.x to Appium1.x (useful frequently. I have answered a few questions ).
Https://github.com/appium/appium/blob/master/docs/en/advanced-concepts/migrating-to-1-0.mdMigrating your tests from Appium 0.18.x to Appium 1.xMigrate your test from Appium version 0.18.x to Appium1.xAppium 1.0 has removed a number of deprecated features from the previous versions. This guide will help you know what needs to change in your test suite to take advantage of Appium 1.0.

Appium1.0 kicked out some old and invalid functions from the old version. If you want to upgrade your test to Appium1.0-based, this wizard will tell you how to do it.

New client librariesNew client library

The biggest thing you need to worry about is using the new Appium client libraries instead of the vanilla WebDriver clients you are currently using. visit the Appium client list to find the client for your language. downloads and instructions for integrating into your code are available on the individual client websites.

The most important thing you need to do is to use our latest Appium client library to replace the original ordinary WebDriver client library, check the Appium client list to find the client version in the corresponding development language you are using. As for how to download and integrate your code, there are corresponding pages for answers.

Ultimately, you'll be doing something like (to use Python as an example ):

In the end, you need to do the following (using Python as an example ):

from appium import webdriver

Instead:

Replace the original:

from selenium import webdriver

New desired capabilitiesNew capabilities options

The following capabilities are no longer used:

The following capabilities will no longer be used:

• device
• version

Instead, use these capabilities:

Replace the following capabilities:

• platformName(Either "iOS" or "Android ")
• platformVersion(The mobile OS version you want)
• deviceName(The kind of device you want, like "iPhone Simulator ")
• automationName("Selendroid" if you want to use Selendroid, otherwise, this can be omitted)

TheappCapability remains the same, but now refers exclusively to non-browser apps. To use browsers like Safari or Chrome, use the standardbrowserNameCap. This means thatappAndbrowserNameAre exclusive.

The capability of the previous app remains unchanged, but this item is currently used for non-browser apps. If you want to test applications based on browsers such as Safari or Chrome, use the standard browserName capability. That is to say, app and browserName are both dedicated options.

We have also standardized on camelCase for Appium server caps. That means caps likeapp-packageOrapp-wait-activityAre nowappPackageAndappWaitActivityRespectively. Of course, since Android app package and activity are now auto-detected, you should be able to omit them entirely in most cases.

At the same time, we used the camel naming method to rename the capabilities of our Appium Server. For example, the original app-package and app-wait-activity will be changed to appPackage and appWaitActivity. Of course, since we can automatically detect Android app packages and activities, you can ignore these options most of the time.

New locator strategiesNew Control finder Policy

We 've removed the following locator strategies:

We removed the following control finder policy:

• name
• tag name

We have now addedaccessibility_idStrategy to do whatnameUsed to do. The specifics will be relative to your Appium client.

We have now introduced the accessibility_id policy to replace what the original name is doing (Note: that is, the original AppiumDriver. findElementByName will be replaced by the current AppiumDriver. findElementByAccessibilityId ). The details will vary depending on the Appium client you are using.

tag nameHas been replacedclass name. So to find an element by its UI type, use the class name locator strategy for your client.

The new class name will replace the original tag name (Note: The original findElementByTagName will be replaced by the desired findElementByClassName ), if you want to find the control based on the UI type of a control, use the class name control finder.

Note aboutclass nameAndxpathStrategies: these now require the fully-qualified class name for your element. This means that if you had an xpath selector that looked like this:

Note the changes in the class name and xpath policies: You need to use FQCN to describe your control. That is to say, if you select an xpath sub-statement as follows:

//table/cell/button

It wocould now need to be:

Now you need to change it to (Translator's note: that is, the original findElementByXpath ("" // TextView [contains (@ text, 'add note')] ""). change to findElementByXpath ("// android. widget. textView [contains (@ text, 'add note')] "):

//UIATableView/UIATableCell/UIAButton

(And likewise for Android:buttonNow needs to beandroid.widget.Button)

(And so on: the button is now written as android. widget. Button)

We 've also added the following locator strategies:

At the same time, we also added the following control positioner Policy (Translator's note: that is to say, we added AppiumDriver. findElementByUiAutomator to the Andoid ):

• -ios uiautomation
• -android uiautomator

Refer to your client for ways to use these new locator strategies.

Determine how to use the new control positioner policy based on the client (based on different languages) you are using.

XML, not JSONReplace XML with JSON

App source methods, which previusly returned JSON, now return XML, so if you have code that relies on parsing the app source, it will need to be updated.

The format returned by the source code of the current window (Translator's note: that is, the AppiumDriver. getPageSource function) will be changed from the original JSON to XML. Therefore, if your previous Code contains the source code of the dependency analysis control, you must update the Code accordingly.

Hybrid support through context, not windowHybrid applications are supported through context rather than window

Hybrid apps were previusly supported by switching between "windows" using:

Previous hybrid applications are supported by switching to "windows:

• window_handles
• window
• switch_to.window

Now Appium supports the more conceptually consistent concept of "context". To get all of the available contexts, or the participating context the application is, you use

Currently, Appium supports a "context" that is more consistent with the context switching concept ". To obtain all available contexts or specific contexts of your application, use the following method:

# pythondriver.contextscurrent = driver.context

// javascriptdriver.contexts().then(function (contexts) { /*...*/ })

// c#driver.GetContexts ()driver.GetContext ()

// javaSet<String> contextNames = driver.getContextHandles();String context = driver.getContext();

// php$contexts = $this->contexts();$context = $this->context();

# rubycontexts = available_contextscontext = current_context

And to switch between them, you use

Perform the following switchover:

# pythondriver.switch_to.context("WEBVIEW")

// javascriptdriver.currentContext().then(function (context) { /*...*/ })

// c#driver.SetContext ("WEBVIEW");

javadriver.context(contextName);

// php$this->context('WEBVIEW');

# rubyset_context "WEBVIEW"

No moreexecute_script("mobile: xxx")
execute_script("mobile: xxx")Disappear

Allmobile:Methods have been removed, and have been replaced by native methods in the Appium client libraries. This means that a method call likedriver.execute("mobile: lock", [5])Will now look something more likedriver.lock(5)(WherelockHas been turned into a native client method). Of course, the details on calling these methods will differ by client.

All methods related to "mobile:" will be removed and replaced by the native method of the Appium client library. For example, the original driver.exe cute ("mobile: lock", [5]) will be used by the current driver. lock (5) is replaced (here the lock function has become a native customer method ). Of course, the specific call method will vary depending on the different client libraries you use.

Of particle note, the gesture methods have been replaced by the new TouchAction/MultiAction API which allows for a much more powerful and general way of putting gestural automation together. refer to your Appium client for usage notes on TouchAction/MultiAction.

It must be specifically stated that the methods related to gesture operations will be replaced by the new TouchAction/MultiAction API, combining these gesture operations will make your gesture operations more automated and easy to understand. For more details about TouchAction/MultiAction usage, see your Appium client.

And that's it! Happy migrating!

Complete! Happy migration!