Shauvik Roy Choudhary
CEO & CoFounder at MoQuality

This is the first in the series of articles towards the ultimate guide for Appium. In the guide, we will share our learnings about Appium and how we think it can help best automate mobile app tests.

What is Appium?

Appium is an open-source test automation framework, primarily designed to support UI testing of native, hybrid and mobile-web apps on iOS and Android mobile platforms. It follows the WebDriver protocol that was standardized for web automation by the W3C, popularized by the Selenium framework. Hence, Appium is also often called as “Selenium for Apps”.

Appium is a popular tool for mobile test automation amongst Automation Engineers a.k.a Software Developer in Test (SDET), as they're called in many companies. Typically such developers use Selenium for web automation and Appium for mobile. In the past few years as mobile automation has become more stable, there has been a rise in Appium users.

Although originally built for mobile automation, Appium has now grown to also support testing of desktop apps on Mac OS X, Windows and also on IoT platforms such as the Raspberry Pi. Thus, it can prove to be a valuable tool across multiple platforms.

How Appium works.

Similar to Selenium, Appium follows a client-server architecture that communicates over HTTP using the WebDriver protocol.

Appium Client Libraries

The clients are implemented in different languages (Java, JavaScript, Python, Ruby, C# and PHP), and run in conjunction with a test harness specific to the language (e.g., JUnit or TestNG for Java, Mocha or Jasmine for JavaScript and so on). Each API call into the library is converted into an Appium command that is sent to the server to perform a task (e.g., launch app, click a button on the screen etc).

Here is a list of the different client libraries.

Note that, for JavaScript, the client libraries are built for both Selenium and Appium. So, the documentation might seem a bit generic.

Appium Server

The Appium server runs on a host computer, that is connected to mobile devices or is running mobile emulators/simulators. The communication with the mobile device is facilitated by a device-specific driver that translates the Appium commands into a platform-specific implementation.

Appium Drivers

Appium drivers implement their commands for each of the platforms. On Android, Appium’s default implementation uses the UIAutomator driver that internally uses Google’s UIAutomator library for black-box testing. There is also an optional, Espresso driver (beta) that can be used to implement gray box testing with the app-under test with a little configuration needed.

On iOS, the XCUITest Driver allows for testing on iPhone real devices and simulators. Testing on real devices requires the need to have an Apple Developer account and configuring the driver with the same.

Appium Drivers exist for other non-mobile platforms as well. We will save their discussion for a later time, in another blog, perhaps.

Here are all the drivers that are available for Appium today.

  • Android: UIAutomator and Espresso (beta) driver
  • iOS: XCUITest Driver
  • Windows: WinAppDriver
  • OSX: Mac Driver
  • IoT with Raspberry Pi Driver

Appium Sessions

The first command that is sent from the Appium client, contains a special request to start a session. This request contains details of the session request in JSON form called as capabilities (caps). This includes details of the platform, device, application under test, and settings that the drivers might support. Once an Appium session is established, subsequent commands are sent to the server for performing the desired testing.

Scaling Appium Setups (Local vs Cloud)

Appium can be run as a server to automate all connected devices or available emulators (or simulators) on the host machine. The Appium server can also act as a Hub (a.k.a. Grid) and mediate access to devices or emulators either on the same machine or on connected Appium servers. This allows for setting up a custom, local test automation farm for cross-device (compatibility) testing. The same setup can also be used for performing automated regression testing when connected to a CI/CD system.

Although this local setup is feasible, it might be an overhead for teams to maintain this device-lab set up with an extensive list of devices. In such a case, you can leverage cloud device farms that support Appium (e.g., Sauce Labs, BrowserStack, etc). These services essentially operate an authenticated Appium server endpoint, which allows running tests on one of the thousands of devices that are stored in their data center, at an economical cost.

Why many testers prefer Appium

We think one of the biggest reasons for Appium's popularity is due to its similarity with Selenium, which has been a leading open-source test automation framework for over a decade. Like Selenium, Appium uses the Webdriver protocol and supports writing tests in a variety of languages. So, it's easy for teams already using Selenium to use Appium, within existing test abstractions and frameworks.

Also, since Appium chooses a black box testing approach by design, its architecture does not require one to have access to the source code of the app under test, but just the application binaries (APK for Android, and IPA for iOS). Thus, it’s a natural fit for QA teams that get a build from the developers and can directly jump into automation without the need to set up or securely access a dev environment. This also allows testers to validate a much closer build of the product that is shipped to the users, thereby eliminating risks where something might work in the dev-build, but fails on production.

Why Appium may not be the right choice for you

Although Appium provides an easy framework to write mobile test automation, it might not be the right solution for all teams. For instance, app developers (and not QA) might prefer to write and maintain tests within the app’s source code by using the frameworks provided by the platforms. This allows them to refactor the tests with the code as changes are implemented, and also potentially have a single test for both the platforms if the apps are implemented in the same fashion (e.g, React-native/Xamarin). However, by using abstractions such as page-object-models, it is possible to implement a single test code for multiple platforms in Appium as well.

Another reason might be that since, Appium is an open-source framework, features or changes introduced by newer versions of iOS and Android, may require updates or patches to specific drivers, which might be available a few weeks to months after the change. However, since mobile automation has become stable in recent years, such breaking changes have been fewer than the early days of Appium.

Getting Started with Appium

Now that we’ve gone over Appium fundamentals, let’s see how we can get started with setting up Appium and use it to test different kinds of Apps.

You can follow our detailed documentation for setting up your machine with Appium dependencies on Mac OSX or Windows. Once set up, you can start Appium from GUI (Appium Desktop) or the command line by typing appium on the command line.

When you see the welcome message, it means that you have an Appium server running on your machine and you’re all set to begin your automation journey!

We hope you enjoyed this article. In the next few series, we will cover examples of how you can start writing Appium tests for different kinds of Apps. Stay tuned!

Shauvik Roy Choudhary
CEO & CoFounder, MoQuality
PhD, Computer Science
Software Testing Tools Expert
Share this Article


Subscribe to the MoQuality Blog.