An introduction to Appium architecture

In our last post, we gave a quick introduction to Appium. We explained what Appium is and its philosophy. Here we will take a look at Appium architecture.

Appium uses the vendor-provided automation frameworks under the hood. Because of this, we don’t need to compile any Appium specific or third-party code or frameworks to the app under test. This is the base of the first philosophy of Appium, you're testing the same app you're shipping. The vendor-provided frameworks that Appium uses are

• iOS: Apple’s UIAutomation
• Android 4.2+: Google’s UIAutomator
• Android 2.3+: Google’s Instrumentation (Support for Instrumentation is provided by a separate project – Selendroid)

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

The full cycle will be something like

1. You write your tests using one of Appium client libraries (which supports Appium’s extensions to the Webdriver protocol)
2. Your tests calls the Webdriver API
3. 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)
4. The Appium server, under the hood invokes vendor specific mechanisms to execute the test commands
5. The client (devices or emulators) responds back to Appium server
6. 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 writing our tests.

If you like the post, don’t forget to share and/or comment.