Appium Introduction : Concepts, Design, Architecture

Appium is a mobile app automation testing tool. It can be used to test apps run on iOS and android platforms. It can test both native, web, and hybrid mobile applications. It is open source.

1. Mobile Native Apps & Mobile Web Apps & Hybrid Application.

1. Mobile native apps are those that are written using iOS or Android SDK.
2. The so-called “mobile web application” refers to applications accessed using a mobile browser (Appium supports Safari in iOS and Chrome in Android).
3. And “hybrid application” refers to the native code that encapsulates a web view — use native code to interact with web page content. This can help developers develop applications using web technology, and then encapsulate them in native code.

2. The Concept Of Appium.

1. To meet mobile automation requirements, Appium follows a philosophy that focuses on the following four requirements:
2. Don’t have to recompile or modify the application for automation.
3. Don’t have to be limited to a certain language or framework to write and run test scripts.
4. A mobile automation framework should not duplicate the wheel of the interface. (mobile automation interfaces should be unified).
5. Open source, both mentally and nominally.

3. Appium Design.

1. So how does the Appium architecture implement this philosophy? To meet the first point, the real work engine of Appium is actually a third-party automation framework. That way, we don’t need to embed Appium related or third-party code in your application.
2. This means that the tested app is not different from the final release. Appium uses the following third-party frameworks:
3. iOS: apple’s UIAutomation.
4. Android 2.3+: Google’s Instrumentation. (Instrumentation is supported by a separate project Selendroid).
5. Android 4.2+: Google’s UiAutomator.
6. Windows: Microsoft’s WinAppDriver.
7. To meet the second point, we encapsulate these third-party frameworks into a set of APIs, the WebDriver API. WebDriver (aka “Selenium WebDriver”) specifies the client to the server-side protocol.
8. Using this client-server architecture, we can write the client in any language and send the appropriate HTTP requests to the server. Most popular language ( java, python, PHP, javascript, etc) versions of the client have been implemented so far.
9. The client library is simply an HTTP client that can sneak into your code in any way you like. In other words, the Appium and WebDriver clients are not technically “test frameworks” but “automation libraries”. You can use these automation libraries in your test environment.
10. In fact, WebDriver has become the standard for web browser automation. Why should we do something completely different for mobile? So we’ve extended the WebDriver protocol and added mobile automation-related API methods on the original basis.

4. Appium Architecture.

1. C/S Architecture: The core of Appium is a web server that provides a set of REST interfaces. It receives the client’s connection, listens to the command, then executes the commands on the mobile device, and then returns the execution results to the client in the HTTP response. In fact, this client/server architecture gives you a lot of possibilities, you can use any language that implements this client to write test code. You can put the server-side in different machines. You can only write test code, and then use cloud services like Sauce Labs to execute commands.
2. Session: The automation process always runs in one session. The client initializes a session to interact with the server, different languages have different ways of session implementation, but eventually, they all send a POST request to the server, the request contains a JSON object, which is called ” desired capabilities “. Then the server starts an automation session and returns a session ID to the client user for subsequent commands.
3. Desired Capabilities: The Desired capabilities are collections of key-value pairs (for example, a map or hash), and the client sends these key values to the server to tell the server how we want to test. For example, we can set platformName capability‘s value to “iOS“, this will tell Appium server, we want an iOS session, not an Android. We can also set safariAllowPopups capability‘s value to “true“, this will make sure that in Safari automatic session, we can use javascript to open new Windows. Please look at the capabilities documentation for a complete list of capabilities.
4. Appium Server: The Appium server is written in node.js. We can compile from source code or install directly from NPM.
5. Appium Client: The Appium client library has been implemented in a lot of languages such as Java, Ruby, Python, PHP, JavaScript, and c #, all of which implement extensions to the WebDriver protocol for Appium. When using Appium, you can simply use these libraries instead of the regular WebDriver library.
6. Appium.app, Appium.exe: There is also a GUI encapsulated Appium server download that encapsulates all the dependencies need to run the Appium server. Use this tool, you do not need to worry about how to install node.js. It also includes an Inspector tool that can help you check the application’s interface hierarchy, which is more convenient when writing test cases.