Appium Architecture for Android Testing
Appium is certainly one of the first tool to come to mind when it comes to mobile test automation. It continues to evolve rapidly with the advantage of open source development.
In this article, I would like to talk about architecture on Appium Android side. Those who want to develop their own automation framework or use this tool more effectively should look at the handy libraries that Appium has in the backplane.
Let’s first look briefly at the Android test libraries, Instrumentation, and UIAutomator’s libraries. Along with allowing you to develop UI test automation in two libraries, there are some differences. The Instrumentation library has been supported since the first versions of Android and many operations can be automated on the application front. However, except for the application context, the native elements such as the alert window, notification, etc. can not be accessed. UIAutomator is a test library which is used together with API 18 and allows easy automation of test automation on the UI of the application and operation system. API 18 and above are able to write much stronger tests with these two libraries.
The Appium is based on small modules that run on the application with the WebDriver protocol. Through these modules, take screenshots of the device, click on the application elements, and so on. Commands are being processed on the device.
This module technically works like this;
- The Java application contains a test derived from the com.android.uiautomator.testrunner.UiAutomatorTestCase class. This test works to run a socket server listening on port 4724 on the device. Uses the Appium UI Automator interface to load and run the test on the device.
- This server gets the commands, converts them to the appropriate Android UI Automator commands and runs them on the device.
Appium includes a small nodejs module for running tests written in UI Automator on Android. With the appium-uiautomator module, you can send and run the jar package containing your test to the device. In Appium, this module is used to run the Bootstrap module.
Finally, let’s talk about Selendroid, which is used to support older versions of Android within Appium. Selendroid is another test tool that you can automate your Android tests on your own. Again with WebDriver protocol, the desired commands can be run on the device. This test framework is built on the Android Instrumentation library. For this reason, it is a good tool for those who want to test on old Android versions with some limitations. His work is as follows;
- The APK to be tested is re-signed.
- The Selendroid test server APK is signed with the same key. (Instrumentation library and target application must be signed with the same key.)
- These APKs are installed on the device.
- The instrumentation test is run via ADB and the server is removed from the device.
After the Appium 1.5. * Version, it was a completely new architecture. Thanks to its modular structure, a number of useful tools that you may need in test development are available on their own and are open source. It would be useful to examine the modules within the Appium architecture in order to be able to use this tool more effectively in developing mobile application test frameworks or in testing processes.
Robotic.Mobi and Running Appium tests in the cloud
With Robotic.mobi test services, you can run your Appium tests in parallel on hundreds of different devices in the cloud. You can get test results as a detailed report consisting of screen images, video, device logs and performance logs.
We will also be able to provide RestApi to access our device lab and create test scripts, or you can run your tests on our devices from your own development environment.