If you count from SeleniumConf 2012 as the date that Appium was born, Appium just turned 5 last week. In the last 5 years, Appium has come a long way in taking mobile UI automation from a haphazard bleeding edge endeavor to an indispensable part of many development teams’ continuous integration system for mobile apps.
At the start, Appium was created to solve one specific problem. I had just taken a new job as the head of QA for a dating site in San Francisco, called Zoosk. We had mobile apps which we were struggling consistently deliver in a timely fashion with high quality. Out of that necessity, Appium was born. The idea was that if we could do this on our web site with Selenium, why couldn’t we do the same thing in the same way on our mobile application.
Having now achieved the ability to automate mobile apps, it’s a good time to go back to the initial problem and realize, perhaps we’re not done yet. What I mean by that is that the initial problem was that I had something that wasn’t a website, but I wanted to automate it just like I automated a website with Selenium. For some platforms, that problem still exists. Appium has solved that problem for mobile apps. However, there’s no reason we can’t take this a step further and solve this problem for any kind of application.
Modern applications no longer execute on a single platform. Take a situation like online food ordering. A customer places an order on a website or an app. Somewhere across town in a kitchen, a tablet gets a push notification and a chef confirms the order. Once the food is nearly ready, a driver is requested and accepts the delivery from his mobile phone. This is a simple example, but as you can see it could involve at least 3 different devices. If you want to write truly end-to-end tests for scenarios like this, you care going to need a framework to do that. As of right now, you might likely have to code in several different frameworks and programming languages to accomplish an end to end test for this, and coordinating those frameworks with one another will prove obnoxious.
To address this problem, Jonathan Lipps of the Appium project, put forth the idea that Appium is StarDriver. StarDriver, a term coined by Jason Huggins, being a play on WebDriver but replacing the “Web” with a wildcard character. StarDriver is the idea that perhaps we can create one protocol for automation across any platform. In creating a mobile implementation of the WebDriver protocol for Appium, a few changes and extensions were needed to the WebDriver protocol, but for the most part, it just worked. With the adjustments made for Appium, it’s become clear that with a bit more work we can find the places the protocol needs generalization and abstraction and create a protocol for automating anything and everything.
Think of writing a multiple platform automation script like composing a symphony. When Beethoven wrote a symphony, he didn’t know how to play each instrument in the orchestra; he used standard musical notation which each musician in the orchestra interpreted to control his or her instrument. What musical notation is to compositions, Appium/StarDriver needs to be to automation. If I want to automate an Android phone, a website, and an AppleWatch, I shouldn’t need to learn how to operate three different frameworks.
I believe that automation across most devices shares enough of a common structure that it can be represented in a protocol and interpreted by implementations for specific platform. Building this protocol will enable developers to build end-to-end tests which can survive framework changes, interoperate on older devices that may not support the most current frameworks, and seamlessly coordinate tests across multiple devices and platforms. In the last year, Microsoft has produced a driver for Appium that controls Windows apps using the same protocol. A basic Mac application driver has also been implemented. Being able to support these 2 platforms in addition to mobile applications and the web strengthens the case that a common protocol can be achieved.
Looking back on 5 years of Appium, I’m proud of what the project has accomplished, but I’m even more excited about what we’ve learned from the work we’ve done and the future of automation which that learning leads us to pursue.