Confused about introduction of client libraries in Appium 1.0

[Dale King]

The major thing that set Appium apart to me were rules 2 and 3:

2. Write tests in any language
3. Use a standard automation specification and API

In Appium 1.0 migration guide it says: "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."

In a thread in this forum it was mentioned: "You can continue to use selenium-webdriver. If you want to use the appium specific features, then the ruby_lib gem is a better fit. "

So this leads to the all important question:

Is there ANYTHING that can be done using the Appium client libraries that cannot be done using the normal selenium driver?

If the answer to that is NO then I really don't see the point of the Appium client libraries or why it is "the biggest thing you need to worry about". If we have a universal, standard way to do things, why would you waste any effort on creating a bunch of optional, non-standard ways to do the same thing. If this is the case then you need to make sure that you document how to do everything with plain old selenium driver.

If the answer to that question is YES, then that means Appium has officially abandoned rules 2 & 3 and can no longer rightfully claim to support them or claims like "you're free to use whatever test runner and test framework you want" or "You can manage your test environment any way you like".

You would no longer be able to say that you can write tests in any language or framework because you would only be able to write tests in a language or framework that supports using one of the client libraries. You could no longer claim that you use a standard automation specifcation and API because tests would need to be written to the library not WebDriver and your client libraries are not a standard. The fact that internally you used WebDriver is meaningless at that point. If there is any need whatsoever for using these new client libraries over standard selenium, then Appium has suddenly become uninteresting.

My situation was that I was writing tests using the Robot Framework and interfacing to Appium through the Selenium2Library-java for Robot Framework. If the client libraries are now required then I have no way to use them unless someone writes a version of the Selenium2Library for the client library. So I would have a test runner and framework that I want to use and would be unable to use Appium 1.0, which violates rules 2 and 3.

So please tell me you have not abandoned the 2 most important rules you were founded upon!

[Jonah Stiennon]

tldr; You can still use the Selenium libraries, but you won't be able to control some of the Appium-specific features.

Rule #2: Write tests in any language.

Appium, and all webdriver projects, accept test commands over HTTP, as a RESTful api. Any language which can send HTTP requests can control Appium or any webdriver. Sometimes I test things with cURL.

If you wanted to write your tests in REBOL, you might have to do more manual work, setting up your individual HTTP requests. A client library is simply this work done for you already.

The Selenium project was designed to control web browsers, as such the JSON Wire Protocol was developed. But mobile devices require automation in ways which were not foreseen. Web browsers don't switch between native apps and web views. Traditional browsers don't load apps, don't put running apps into background processes, don't hide keyboards and lock screens.

There are functions beyond those provided for in in the JSON Wire Protocol, and the selenium libraries which mobile developers want to be able to test.

So there's MANY things which can be done on Appium which cannot be done with Selenium.

The Selenium project predicted that other people would write client libraries for testing different sorts of things. They provided the base functionality but allow for extension all over the place. We have extended the libraries to handle functions that Appium can test, which normal web drivers cannot.

Yes you can use the client libraries that the Selenium project provides. In fact, we are working to merge a lot of our changes into the Selenium clients.

3. Standard Specification API

The standard you refer to is the JSON Wire Protocol and the WebDriver spec. But lo, there are newer standards being developed. The appium client libraries added support for the new WebDriver spec, (https://dvcs.w3.org/hg/webdriver/raw-file/default/webdriver-spec.html) which is being adopted by the Selenium project, but hasn't been implemented yet.

Plus, there is the Mobile JSON Wire Protocol, of which the Appium client libraries are the first to conform to, but will (hopefully) not be the last.

https://code.google.com/p/selenium/source/browse/spec-draft.md?repo=mobile

[Jonathan Lipps]

Thanks for your questions, Dale. I'd like to build on what Jonah has already said.

First of all, the new client libraries don't AFAICT touch on rule #2 (use any language). The crux of the issue is what it means to use a "standard automation specification". Initially, this meant the WebDriver protocol. It soon became clear to us and others working on WebDriver-based automation frameworks that WebDriver was not going to cut it. That's why we met with the leaders of the Selenium project last year to come up with a new mobile spec draft[1]. Many of the changes in Appium 1.0 are implementations of this new spec: TouchAction/MultiAction-based gestures (instead of using mobile: xxx methods), XML source instead of JSON, new locator strategies (and deprecations of old web-based ones). Since we had a launch schedule we needed to hit, we put this functionality into Appium clients. But we're now working on getting them into the official WebDriver bindings and deleting those methods from the Appium clients. So stay tuned for that!

That doesn't cover everything, though. There are a number of methods that Appium exposes as a convenience for its users that we decided (at the mobile spec "summit") should not be a part of an actual mobile automation standard, because they provide peripheral functionality not core to the automation of a mobile app itself. Some examples: checking whether an app is installed, installing/uninstalling an app during a test, pushing/pulling data to/from a device, seeding a device with content, resetting an app's state during a session, etc… The group decided that doing these things (essentially, setting up and managing the test environment) is really the responsibility of the tester, not the automation tool, and hence shouldn't be part of the spec. I completely agree! However, because we want Appium to be as useful as possible and not force our users to continually come up with techniques which could be a useful extension to the core automation technology, we continued to bundle these features with Appium. Previously, they were exposed with a hacky extension of execute_script. But the WebDriver spec actually defines a way to expose custom extensions to clients! It involves modifying the JSONWP with new vendor-specific endpoints[2]. Thus in order to be even more standard, we decided to move all of this into the custom /appium extension to the HTTP API. Of course, we now need a way to access these new endpoints. There were two options: 1) give people code snippets for how they might go about extending their vanilla WebDriver client on their own. Some clients (like Python) make this really easy (creating new methods which simply call an internal "execute" function). With other clients, it might not be so easy. The other option is 2) putting this extension-calling code into clients we distribute. Ultimately we decided on #2, knowing that forcing people to write their own code to access the extension would drastically limit people's use of the methods.

That still doesn't cover everything! There are a few more methods (like shaking, rotating [by degrees], and locking the device) that one could argue should be part of the automation tool itself. We'll continue to discuss the possibility of getting these added to the mobile spec with the rest of the group working on that spec. But that could take a long time. Meanwhile, they're ready to use today in the Appium client!

So essentially we have the Appium clients for 3 reasons:

1) There wasn't time to go through a full commit and release cycle for Selenium once we'd set a release date for 1.0

2) Some of the things that Appium does, and which its users really find useful, are never going to be an official part of the new mobile spec. We want a way to make these extensions available

3) There are some behaviors whose state is as yet unknown. They might make it into the spec and get deleted from the clients, or they might be in category #2

Ultimately, the only reason for the clients will be #2. And even that is actually evidence that we are conforming to the WebDriver spec (by implementing the extension strategy it recommends) rather than departing from it. In the future, I think it'd be great to have guides on how to use vanilla WebDriver clients and add code snippets to them in order to give them access to the Appium-specific methods. But for most people, using the Appium clients will continue to be the easiest and cleanest way to use Appium.

Fortunately, the list of methods in #2 is a pretty esoteric set of things that you could either avoid completely or reimplement using shell commands in your test scripts. What this means is that, once we've got the mobile spec stuff merged into the official WebDriver clients, for most users, you probably won't need an Appium client.

And in any case, none of the 3 motivations for having Appium clients violates (again AFAICT) rule #3.

Happy to dialogue further with anyone who has more questions about this strategy!

-Jonathan

[1] https://code.google.com/p/selenium/source/browse/spec-draft.md?repo=mobile

[2] https://dvcs.w3.org/hg/webdriver/raw-file/default/webdriver-spec.html#extending-the-json-http-protocol

--
http://appium.io
---
You received this message because you are subscribed to the Google Groups "Appium-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to appium-discus...@googlegroups.com.
Visit this group at http://groups.google.com/group/appium-discuss.
For more options, visit https://groups.google.com/d/optout.

[William Zhang]

You can try robotframework-appiumlibrary https://github.com/jollychang/robotframework-appiumlibrary

It is based on Appium 1.0+

Welcome pull requests :)