This is the second in a 2-part series on automation testing using real iOS devices with Appium.
Assuming you have gone through all the setup instructions in the first part of this guide. Now we’ll be able to put it all together in the form of actual Appium scripts.
How Appium Works On Real iOS Devices
UI testing of any device depends on the ability to launch an app and have another program inspect and interact with what the app displays on the screen.
iOS has very strict security requirements and prevent one app from looking at what is going on in another app. In order to provide this necessary feature for testing apps, Apple built the XCUITest framework.
The way it works is that Xcode can build a special app called “XCUITest-Runner”. The XCUITest-Runner app has access to a special set of system functions which can look at the UI elements of another app and interact with them. These special functions are called the XCUITest API, and sparse documentation about them can be found.
When running tests, Xcode will installs both the AUT(application under test) and the runner app on the device. The runner app is a special package which includes the actual tests we wrote, and the name of the AUT. Xcode tells the device to launch the runner app, and the runner app launches the AUT. Both the runner app and the AUT are active on the device. The runner app is invisible and works in the background, while the AUT is displayed on screen.
After the AUT launches, the runner app goes through its list of tests and runs each test, looking at the UI of the AUT and calls the special XCUITest API functions for tapping, swiping, typing.
UI tests are usually compiled and embed into the runner app which is loaded onto the device, but Appium needs to be able to control the device as you send commands to Appium server and do dynamic test, rather than following a predetermined script. What we need is a test that can be any test, rather than following a set of specified user actions.
Facebook came up with a bright idea and published a special test framework called WebDriverAgent (WDA). Essentially, WDA is a runner app that opens a connection to the outside world and waits for commands to be sent to it, and convert command to existing XCUITest API methods. Also WDA is designed to use the WebDriver protocol for the format of these commands, the same protocol that Appium already uses for its test commands.
That means when Appium tests run, they are using an Appium client to send WebDriver commands to the Appium server. The Appium server will install both AUT and WDA on the iOS device, waits for WDA to start, then forwards your test commands to WDA. WDA executes XCUITest API functions on the device, corresponding to the commands it receives from the Appium server. In this way, we are able to interact with the UI of an iOS device.
Appium Test Capabilities
Now we know how Appium works and we have the app running on our device, all we need to do to make our test work is use the right set of Appium capabilities:
Desired capabilities usages:
- platformName: is iOS
- platformVersion: is the version of iOS our app is running
- deviceName value for deviceName
- udid: is the unique ID of the device we want to run our test on
- bundleId: bundle ID of the app under test
For more capabilities, please refer: link
Write and run your test
You only need to instantiate a Appium driver and follow the Appium api to write your test scripts and trigger the run button. All the heavy work is done by appium. Here is a step-by-step guide on how to do it:
- Start the Appium server (by opening the Appium Desktop app or using the CLI).
- Run the Python test you wrote including the capabilities above
- Make sure the device is unlocked, and if it asks you to “Trust the Computer”, tap the button to trust our Mac. You’ll need to do this the first time.