Architecture of Appium - Notes By ShariqSP

Architecture of Appium

Appium is an open-source automation framework designed to test mobile applications across different platforms. It follows a client-server architecture where the components interact with each other to perform testing tasks. Here's a breakdown of its architecture:

Key Components of Appium

• Appium Server: Acts as a central hub. It receives requests from the client (via JSON Wire Protocol or W3C WebDriver Protocol) and executes them using device-specific drivers.
• Appium Client: The test scripts written in various supported languages (Java, Python, Ruby, etc.) interact with the Appium Server.
• Drivers: Appium uses different drivers to automate different types of devices:
  • UIAutomator2 Driver: For Android devices (API Level 21+).
  • Espresso Driver: For Android devices with native applications.
  • XCUITest Driver: For iOS devices (Xcode 8+).
  • Windows Driver: For Windows desktop applications.
  • Mac Driver: For macOS desktop applications.
• Device/Simulator: The target platform where the application is tested. It could be an emulator, simulator, or physical device.

How Components Are Connected

The following diagram illustrates the Appium architecture and its connections:

                    +------------------------+
                    |      Test Script       |    (Appium Client)
                    +------------------------+
                              |
                              v
                    +------------------------+
                    |    Appium Server       |
                    +------------------------+
                      |         |          |
                      v         v          v
             +-----------+ +---------+ +---------+
             |UIAutomator| | Espresso| | XCUITest|
             +-----------+ +---------+ +---------+
                      |         |          |
                      v         v          v
              +-------------------+ +---------------+
              |    Android Dev    | |   iOS Devices |
              +-------------------+ +---------------+
                  

How It Works

1. The client sends requests (e.g., actions like tapping, swiping) to the Appium Server.

2. The Appium Server identifies the target platform and forwards the request to the appropriate driver.

3. The driver executes the command on the target device (physical or virtual).

4. The results are sent back to the client through the server.

How Appium Communicates Using HTTP Requests and Responses

Appium follows the client-server architecture and communicates through HTTP requests and responses based on the JSON Wire Protocol (deprecated) or the W3C WebDriver Protocol (current standard). These protocols enable Appium to interact with mobile devices by sending automation commands and receiving results.

Key Components in Communication

• Client: The test scripts written in supported languages such as Java, Python, or Ruby act as the client. These scripts use Appium client libraries to send HTTP requests to the server.
• Appium Server: A Node.js server that processes the incoming HTTP requests, routes them to the appropriate driver, and sends back the response.
• Driver: The platform-specific driver (e.g., UIAutomator2, XCUITest) executes the commands on the target device or simulator/emulator.

Steps in Communication

1. Session Creation:

   The client sends a POST request to the Appium Server to start a new session. The request includes desired capabilities, such as the platform name, device name, and application details.

   POST /session HTTP/1.1
Content-Type: application/json
{
"desiredCapabilities": {
"platformName": "Android",
"deviceName": "Pixel_3",
"app": "/path/to/app.apk"
}
}
2. Command Execution:

   Once the session is established, the client sends HTTP requests for specific actions, such as clicking an element, entering text, or swiping.

   POST /session/:sessionId/element/:elementId/click HTTP/1.1
Content-Type: application/json
{
"id": "element123"
}
3. Response from Server:

   The server processes the request, executes it on the device via the driver, and sends an HTTP response containing the result.

   HTTP/1.1 200 OK
Content-Type: application/json
{
"value": "Command executed successfully"
}
4. Session Termination:

   The client sends a DELETE request to terminate the session once the test execution is complete.

   DELETE /session/:sessionId HTTP/1.1

Detailed Example Flow

Let’s take an example of finding an element and clicking it on an Android device:

1. Find Element:

   The client sends a POST request to locate an element using a strategy such as XPath.

   POST /session/:sessionId/element HTTP/1.1
{
"using": "xpath",
"value": "//button[@text='Submit']"
}
2. Click Element:

   After receiving the element ID in the response, the client sends a click request.

   POST /session/:sessionId/element/:elementId/click HTTP/1.1

Diagram Representation

                  Client (Test Script)
                          |
                  +------------------+
                  |   HTTP Request   |
                  +------------------+
                          |
                          v
                  +------------------+
                  | Appium Server    |
                  +------------------+
                          |
                  +------------------+
                  |   Driver (e.g.,  |
                  |   UIAutomator2)  |
                  +------------------+
                          |
                  Target Device/Emulator
                  

Comparison of UIAutomator, Espresso, and XCUITest

UIAutomator, Espresso, and XCUITest are popular frameworks for mobile app testing. Each has unique characteristics tailored to specific use cases and platforms. The following table highlights the key differences:

Summary

UIAutomator: Best for end-to-end and system-level testing across Android apps.

Espresso: Ideal for testing a single Android app, providing fast and reliable results.

XCUITest: The go-to framework for testing iOS applications with native support in Xcode.