Let’s begin with some interesting trivia. Way back in 2011, a Test Manager - Dan Cuellar was at his wits’ end as the length of the test passes on the iOS product was getting unmanageable! Instead of tearing his hair however, he set his grey cells ticking. Dan realized that automation was the answer, but the existing tools just would not do. Recalling his past experience with websites, he applied all his technical experience and prowess, and in 2011, developed "iOSAuto" written in the C# programming language –the very first version of Appium.
Jason Huggins, co-creator of Selenium and a great supporter of open source technology later got in touch with Dan. They brainstormed together on many things including a better name for iOSAuto and hit the nail on Appium – promoting it as the Selenium for Apps. The program was open-sourced in August 2012 using the Apache 2 license. In January 2013, Appium got that much needed thrust when Sauce Labs agreed to fund Appium's development and motivated its code to be rewritten using Node. From then on, there was no looking back!
Appium grew rapidly and the next milestone was the release of Appium 1.0 in May 2014. With awards galore, Appium went on to become a highly popular open-source cross-platform mobile automation framework. Sauce Labs donated more developers to focus attention on Appium, and via the open source code, many others contributed to the project. As the code base grew, there was need for change and so the committer team rewrote Appium with a modern JavaScript and reworked the architecture to facilitate users and third-party developers to build their own Appium “drivers”. This prompted, groups like Microsoft and Youi.tv to add drivers to Appium for their respective apps viz. Windows desktop app automation and Youi.tv app automation – increasing Appium’s universality!
The success of Appium comes from the fact that it is a free open source mobile application UI Testing framework for native, hybrid and web application testing, and also supports a wide spectrum of test automation be it on physical devices; emulators, simulators, or both. Furthermore, it enables cross-platform application testing with a single API working well for Android as well as iOS platform test scripts. Since the Appium framework translates Selenium Webdriver commands into UIAutomation (iOS) or UIAutomator (Android), it’s commands are executed based on device type, eliminating dependency on mobile device OS. This enables code reuse between iOS, Android, and Windows test suites.
Another advantage of Appium is that it supports all languages that have Selenium client libraries like Java, Objective-C, JavaScript with node.js, PHP, Ruby, Python, C#, etc.
The philosophy behind Appium is that testing native apps shouldn’t necessitate the inclusion of an SDK or recompilation of the app. It strongly advocates testers’ liberty to use test practices, frameworks and tools of their choice. Appium’s goal is to automate mobile apps irrespective of their programming language and test frameworks, and provide full access to back-end APIs and DBs from test codes. Thus Appium makes mobile app testers the focus of attention, catering to their needs, bringing testing ease and exhilaration, earning its title as “the safe opium for mobile app testers”.
A closer look at Appium’s design reveals that its philosophy is not just something that looks good on paper but has been thoughtfully integrated into its design. For starters, to ensure you can use the framework of your choice, Appium has used various vendor provided frameworks e.g. for iOS 9.3 and above: Apple's XCUITest, iOS 9.3 and lower: Apple's UIAutomation, Android 4.3+: Google's UiAutomator/UiAutomator2, Windows: Microsoft's WinAppDriver.
Coming to programming language, the vendor-provided frameworks are wrapped in one API, the WebDriver API, which specifies a client-server protocol known as the JSON Wire Protocol. This client-server architecture makes it possible for, a client written in any language, to be used to send the relevant HTTP requests to the server. Furthermore, there are already clients written in every popular programming language, enabling testers to use test runners and test frameworks that they like the best. The client libraries are like HTTP clients which can be merged into the code the way the tester decides. Thus the Appium & WebDriver clients are automation libraries to help manage your test environment as per your choice.
Another wise decision related to Appium is that what’s tried and tested shouldn’t be unnecessarily discarded, but instead be enhanced to your advantage. Since the WebDriver API is the practical choice for automating web browsers, and is a W3C Working Draft, Appium has extended the protocol with extra API methods which are helpful for automating mobile app testing. Appium has also steadily stayed in line with the original thought process, of being an open source mobile test automation framework – freely available for the benefit all.
Let’s now briefly touch upon the Concepts of Appium.
-
Client/Server Architecture
Appium’s core Client/Server Architecture enables it to receive connections from a client, listen for commands, execute the commands on a mobile device, and revert with an HTTP response representing the result of command execution. The advantage of this architecture is that test codes can be written in any language that has an http client API, although it is easier to use one of the Appium client libraries. This architecture also enables the server to be on a different machine than the one on which the tests are run. Going even further, cloud services can be used to receive and interpret the commands for the test codes that have been written. -
Session
Another concept followed in Appium, is that automation is always done w.r.t. a session. When a client begins a session, a POST or session request is sent to the server with a JSON object called 'desired capabilities' object. The server starts up the automation session and reverts with a session ID which is used for sending additional commands. -
Desired Capabilities
'DesiredCapabilities' help the user control the session request with the server. They are a set of keys and values sent to the Appium server to let the server know the kind of automation session that is sought to be used. In addition, there are capabilities that can modify the behavior of the server during automation e.g. setting the platform name to iOS, Android or Windows – according to which session one desires. Or if the 'safariAllowPopups' capability is enabled during a Safari automation session, the use of JavaScript will be allowed to open up new windows. There are many such capabilities available for Appium. -
Appium Server
Appium is a server written in Node.js. It can be built and installed from source or installed directly from NPM. -
Appium Clients
There are client libraries (in Java, Ruby, Python, PHP, JavaScript, and C#) which support Appium's extensions to the WebDriver protocol, to enable the use of various client libraries instead of the WebDriver client. -
Appium Desktop
The GUI wrapper around the Appium server can be downloaded for any platform and has all that is needed to run the Appium server without getting bogged down with Node. There is also an Inspector, which helps check the hierarchy of your app. This is very useful when writing tests.
The good news for mobile app testers is that they don’t have to be constrained by the limitations of Appium, because there are platforms like BOTm that pack in all the benefits of great testing aids like Appium and go way beyond to offer the latest in the mobile app testing world, by incorporating the power of AI and ML testing tools. You can get yourself a free trial at botmtesting.com to experience quick, error-free mobile app testing across spectrum – on a single platform! So go right ahead and try it out today!