Developing a mobile app is just the beginning. To make sure your app is running fine over 3 billion strong Smartphone carrying audience using all types of devices, mobile operating systems, and new and old versions of everything. That takes a lot of mobile testing. The only way to cover it all is with automation testing and in this introductory Appium tutorial post, we will introduce to Appium, Design concepts in Appium and Appium Architecture.
It’s no surprise, then, that developing, testing, and releasing quality mobile apps quickly and efficiently is a high priority for most organizations—as it should be! Fortunately, mobile development tools are evolving to meet these needs, with modern development teams having access to better test automation than ever before. Say Hello to Appium, the most popular automation testing tool for mobile software testing.
1 Hello Appium
Appium, an open-source tool for automating mobile applications on iOS and Android platforms has been around in one form or another since 2012. Since its early days, Appium has grown and matured significantly.Go ahead and get started.
In January 2013, Sauce Labs decided to fully back Appium and provide more developer power. Since then, Appium has been given various awards and is now the most popular open-source cross-platform mobile automation framework.
Stability of the tool has improved, bugs prioritized and fixed, and features have been added. Sauce Labs has now increased the number of developers it donates to working on Appium, but the entire community is involved in guiding the project and contributing to it, and project governance happens in the open, on public mailing lists and GitHub’s issue tracker.
Appium allows native, hybrid and web application testing and supports automation test on physical devices as well as on emulator or simulator both.
2 Design Concepts of Appium
Appium was designed to meet mobile automation needs according to a philosophy outlined by the following four tenets:
- You shouldn’t have to recompile your app or modify it in any way. Say if you have to modify your app to automate it, you are at risk. Because you tested one version of the app (modified one) and you are submitting another version to app stores. Appium allows you to test the same app (without any modifications) that you will be submitting to app stores.
- You shouldn’t be locked into a specific language or framework to write and run your tests. If a tool limits you to write tests in a particular language then you might use it or NOT, based on many factors, including but not limited to language familiarity, developers support, online help etc. Appium gives the flexibility to write automated test in almost any language (Java, C#, Ruby, Python etc.)
- A mobile automation framework shouldn’t reinvent the wheel when it comes to automation APIs. Selenium has become a standard for web automation. So if you are already familiar with Selenium, you know Appium 🙂
- A mobile automation framework should be open source, in spirit and practice as well as in name!. This is pretty self-explanatory.
So how does the structure of the Appium project live out the philosophy that we discussed above?
- Requirement #1 is met by using vendor-provided automation frameworks under the hood. That way, one don’t need to compile in any Appium-specific or third-party code or frameworks to your app. This means you’re testing the same app you’re shipping. The vendor-provided frameworks used in Appium are:
- iOS: Apple’sUIAutomation
- Android 4.2+: Google’sUiAutomator
- Android 2.3+: Google’sInstrumentation. (Instrumentation support is provided by bundling a separate project, Selendroid)
- Requirement #2 is met by wrapping the vendor-provided frameworks in one API, theWebDriver WebDriver (aka “Selenium WebDriver”) specifies a client-server protocol (known as the JSON Wire Protocol). Given this client-server architecture, a client written in any language can be used to send the appropriate HTTP requests to the server. There are already clients written in every popular programming language that you can find at http://appium.io/downloads. This also means that you’re free to use whatever test runner and test framework you want; the client libraries are simply HTTP clients and can be mixed into your code any way you please. In other words, Appium & WebDriver clients are not technically “test frameworks” — they are “automation libraries”. You can manage your test environment any way you like!
- Requirement #3 is met in the same way: WebDriver has become the de facto standard for automating web browsers. Appium developers have extended the protocol with extra API methods useful for mobile automation.
- Requirement #4 is self-explanatory.
3 Internal Architecture
Appium at its core is a webserver written in Node.js that exposes a REST API. The Appium server does the following.
- Receives connections from a client and creates a session
- Listens to the commands
- Executes the commands (on real devices or emulators)
- Responds back with a HTTP response representing the results of the executed commands
As per the figure, the full cycle will be something like
- You write your tests using one of Appium client libraries (which supports Appium’s extensions to the Webdriver protocol)
- Your tests calls the Webdriver API
- The Webdriver sends the request in form of JSon via http request to the Appium server. (Your Webdriver scripts and Appium server can be on same machine or different machines, depending how you want it to be)
- The Appium server, under the hood invokes vendor specific mechanisms to execute the test commands
- The client (devices or emulators) responds back to Appium server
- Appium server logs the results in console.
That’s pretty much it about Appium architecture. There are a couple of additional concepts (like session and desired capabilities), we will explain them when we actually start setting up Appium and do hands on.
4 Appium’s Pros and Cons:
Atlast, I want to pin point few of the pros and cons of using Appium as Mobile Apps Automation Testing Tool.
- The beauty of Appium is that, all the complexities are under the hood of Appium server and for an automation developer the programming language and the whole experience would remain same irrespective of the platform he is automating (iOS or Android).
- The other benefits of Appium is that it opens the door to cross-platform mobile testing which means the same test would work on multiple platforms.
- Unlike other tools Appium doesn’t require you to include some extra agents in your app to make it automation friendly. It believes in the philosophy of testing the same app which we are going to submit in the app store.
- It is developed and supported by Sauce Labs and it is getting picked really fast with in the WebDriver community for mobile automation.
- It can automate Web, Hybrid and Native mobile applications.
- Scaling up is an important consideration with Continuous Integration and Appium comes across as a great tool to fulfill this expectation. The reason for this is a technical limitation, in iOS we can only run one instance on Instruments per Mac OS so we can only run our iOS scripts on one device per mac machine. So if we want to run our tests on multiple iOS devices at the same time then we would need to arrange the same number of Mac machines, which would be costly affair. But this limitation can be resolved if we execute our scripts in Sauce Lab’s mobile cloud which at present supports running scripts on multiple iOS simulators at the same time.
- Appium uses UIAutomator for Android automation which only supports Android SDK Platform, API 16 or higher so to support the older APIs they have used another open source library called Selendroid. So I would not say it as a limitation but it is definitely an overhead on the configuration side.
I have also developed a popular Appium Tutorial course which will teach you the basics of mobile software testing, automating browsers apps, working with appium for android and appium for ios which will get you up to speed with landing a job as mobile automation testing engineer.