Basics of Appium Mobile Testing
When Appium is installed then a server is set up on your machine that exposes the REST API. It receives a command request from the client and executes that command on Android or iOS mobile devices. Then it responds back with an HTTP response. It uses mobile test automation frameworks like Apple instruments or UIAutomator2 to drive the UI of apps.
Approaches to Test Automation
There is two approaches for mobile test automation, Image-based and Object-based approach. Let’s understand both in detail.
Image-Based Approach for Test Automation
This technique of object identification is based on the image processing attributes of the objects in the Application Under Test (AUT). Example: Automate user options like “click, type, drag-drop, mouse actions, etc.”
Visual verification of the expected output
* Not dependent on the platform underneath
* Can be used to automate emulators as well as a real device.
The object-based approach of test automation
This technique of test automation is based on recognizing the nativity of the objects in AUT. This nativity reorganization process for each individual object in the application is carried out using different attributes that are assigned to the object.
It is used to extract the application object identifier with its properties from the actual native operating system source code, just like the developer used. This is an accurate and fast method to recognize the buttons, lists and other objects used by the application.
One drawback of the object-based approach is that the recognition of the individual attributes of the object involved restricts these techniques ability to function in test scenarios that require third-party application access. This reduces the automation coverage of utilizing this technique.
Which approach should we choose?
As we have seen, both approaches have their pros and cons. To get better results, you can merge both approaches and think about devising a hybrid test automation solution.
The combination of OCR (image based) and native (object-based) approach allows users to build a single script that will be portable across different devices. It will make your automation robust and efficient and allows the users to confidently detect the relevant native and GUI defect within the mobile application.
Appium Overview and Architecture
The Webdriver Script sends a command in the form of HTTP (JSWP) to the Appium Server. Then the Appium Server will then decide as per the request which driver should be initiated. So, in this case, the Appium Server will initiate the XCUITest driver and it will pass the request to the WebdriverAgent which is an IPA (WebdriverAgent.xcproj) developed by Facebook. WebdriverAgent is responsible to send the command to the Application Under Test (AUT) to carry out the actions in the app. Then the response will be sent to the Webdriver Script through the Appium server.
Only iOS 9.3 and above version are supported by the XCUITest Driver. You can find all the capabilities for XCUITest Driver in the link mentioned below.
The situation is very similar in the case of Android where Appium proxies command to a UIAutomator2 test case running on the device. UIAutomator2 is Android’s UI automation framework which supports running JUnit test cases directly into the device into the command line. It uses Java as the programing language but Appium will make it run from any of the web drivers supported languages.
To answer the question “what is Appium automation?”, let’s have a look at the Appium philosophy.
Appium mobile testing is required for proper execution of continuous integration as it speeds up the overall testing process. Appium mobile testing helps to run the repetitive test which would take more time to perform manually. This is why appium mobile testing is the preferred choice for the developers when it comes to test automation.
In the next blog, we will learn more about Appium mobile testing and how to install/configure the Appium setup on a windows machine.