The Appium Philosophy

Appium is a rising star in the mobile test automation landscape, and since a few of our developers here at Sauce Labs are regular committers to the project, it’s pretty close to our hearts. You’ll often find Sauce devs hanging out on the Appium Google group answering questions, musing about testing strategies, and helping folks tweak their configurations or hunt down bugs. When it comes to mobile test automation, in many ways we’re still figuring out what the best approaches are, and with Appium, we’ve had the benefit of lessons learned from early automation solutions that didn’t quite work as well as we’d hoped. Some of these lessons are nicely summarized in Appium’s four-point philosophy:

Let’s explore these four points, shall we?You shouldn't have to recompile your app or modify it in any way in order to automate it.

Some early attempts at mobile test automation were based around OCR and pixel-based interactions, which history tells us are never very reliable. After that we saw the introduction of in-app agents that can execute the underlying code that would otherwise be triggered by a user interacting with the app. These agents then make calls to the same code triggered by user actions, like swipes and taps and pinches. It’s not a bad solution, but the gotcha is that you have to compile these agents into your app while it’s being tested, and you probably want to take it out after the testing is done. The result? You’re not actually testing the code that you release.

The agent approach is a bit odd, too, since the real-world user actions are always from outside the app itself, and so if you’re simulating those actions inside the code rather than triggering them by their corresponding UI action, you’re that much further away from the real experience of an actual human user.

In order to solve this problem and provide for testing with these more real-world style user interactions, both Apple and Google have created user interface automation frameworks for their respective development environments. Google provides uiautomator, which is a Java API for simulating these UI actions on Android devices and emulators, and Apple provides UI Automation Instruments, a JavaScript programming interface for use with iOS devices and simulators.

Appium works by interfacing with these vendor-provided automation frameworks, translating your test code into the platform-specific interactions. We think this is a better approach than using an agent, since you don’t have to compile a test build that contains code which will not be in the production build. You’re best off testing the same code you will release.

The next two points of the Appium philosophy are covered together since they both derive from the decision to implement the WebDriver API and JSON Wire Protocol:

You shouldn’t be locked into a specific language or framework to write and run your tests.

A mobile automation framework shouldn’t reinvent the wheel when it comes to automation APIs.

WebDriver is already well-known as the engine behind Selenium 2 test automation for Web apps. In the Appium implementation, instead of driving a Web browser on a desktop operating system as Selenium does, Appium drives native apps and browsers on mobile operating systems. Many testers are already very familiar with writing and running tests locally using Selenium WebDriver, where your test will open a browser, run through some interactions with the app, and verify that the test case passes. But the magic of WebDriver really happens when it’s used in a distributed fashion. Instead of making local calls directly to the browser, the WebDriver test becomes an HTTP client and makes requests to a WebDriver server, which in turn actually makes the necessary calls to the browser and app. The elegance of Appium is that it utilizes this framework to interact, not with a desktop browser, but with Android’s UI Automator or Apple’s UIAutomation Instruments, which then perform user actions on the native app or mobile browser running in either an emulator or a real device. And of course Sauce Labs’ infrastructure can manage all of this for you!

One of the great features of WebDriver is that you can write your test code in your language of choice, since there are WebDriver client libraries for pretty much every popular language out there. The code you write represents the actions users perform on your application under test, and WebDriver can be used with most test runners and frameworks, so chances are your Appium tests can simply be added to your team’s existing workflows.

And so the real-world benefits of the second two points of the Appium philosophy unfold from there. Because Appium implements the WebDriver API, you don’t need to reinvent that wheel. Because WebDriver is so widely used, you can choose any language and test framework and thus incorporate Appium tests easily into your existing process.

A mobile automation framework should be open source, in spirit and practice as well as in name!

Finally, Appium is proudly Open Source and hosted on GitHub. With over 4800 commits, 2000 issues closed, 3400 pull requests, 1100 forks, 1300 stars and dozens of contributors, Appium is a hotbed of excitement and activity in the open source world. The results are spectacular!

And the fun has only just begun!  Look for Appium to continue to evolve rapidly, guided by its core philosophy, and helping you do what you do best, which is delivering great apps to your users!

- Michael Sage, Principal Technology Evangelist, Sauce Labs

Michael Sage is a Principal Technology Evangelist at Sauce Labs who helps software teams develop, deliver, and care for great apps. He’s spent over 15 years as a solutions architect and consultant with software companies including Mercury Interactive, Hewlett Packard, and New Relic. He lives in San Francisco, CA.