In this way, we are able to arbitrarily interact with the user interface of an iOS device. WDA in turn executes XCUITest API functions on the device, corresponding to the commands it receives from the Appium server. The Appium server installs both your app and WDA on the iOS device, waits for WDA to start, then forwards your test commands to WDA.
When your Appium tests run, they are using an Appium client to send WebDriver commands to the Appium server. The creators of WDA chose to use the eponymous WebDriver protocol for the format of these commands, the same protocol that Appium already uses for its test commands. Essentially, WDA is a runner app which opens a connection to the outside world and waits for commands to be sent to it, calling the relevant XCUITest API methods for each command. Some bright minds at Facebook came up with a way to do this and published a special test called WebDriverAgent (or WDA). What we need is a test which can become any test, rather than following a prescribed set of user actions. UI tests are usually compiled 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 it, rather than following a predetermined script. It does this using the special XCUITest API functions. Why is Real Device Cloud Critical in App Testing?Īfter the AUT launches, the runner app goes through its list of tests and runs each test, looking at the user interface of the AUT and tapping, swiping, typing into it, etc. The runner app is invisible and works in the background, while the AUT is displayed on screen. From this point forward, both the runner app and the AUT are active on the device. Xcode tells the device to launch the runner app, and the runner app launches the AUT. The runner app is a special package which includes the actual tests we wrote, and the name of the AUT. When running tests, Xcode installs both the AUT and the runner app on the device. (For the rest of this explanation, we'll refer to the app we are trying to test as the "app under test" or AUT, and the XCUITest-Runner app as the "runner app".) These special functions are called the XCUITest API, and sparse documentation for them can be found here. The XCUITest-Runner app has access to a special set of system functions which can look at the user interface elements of another app and interact with them. The way it works is that Xcode has the ability to build a special app called an "XCUITest-Runner" app. In order to provide this necessary feature for testing apps, Apple built the XCUITest framework. iOS is very strict about security and works hard to prevent one app from looking at what is going on in another app. User Interface Testing of any device relies upon the ability to launch an app and have another program inspect and interact with what the app displays on the screen.
APPIUM SETUP ON MAC FOR ANDROID INSTALL
To get started testing right away, skip to the next section, but if you're wondering why we've had to install some of the things we need, read on. You don't need to understand how Appium controls iOS devices in order to run and write your tests, but I haven't found a written explanation of this anywhere else, so am including it for those who are curious. Assuming you've gone through all the setup instructions in the first part of this guide, we'll now be able to put it all together in the form of actual Appium scripts. It's a tutorial on getting started from scratch, authored by Appium contributor Jonah Stiennon.
APPIUM SETUP ON MAC FOR ANDROID SERIES
This is the second in a 2-part series on using real iOS devices with Appium.
0 kommentar(er)
