Creating test scripts from scratch can be a very tedious process, especially when you have many different flows to create. If you have no access to the tested app’s source, you’ll have to figure out an efficient way to map the app’s UI. The methods that we know of and are about to explain here are all related to using the Appium inspector or uiautomatorviewer for native apps.
Create a Library for App Elements
One good way to handle multiple flows is to first create a library of all the elements you need to interact with. Simply navigate through the whole app with the Appium Inspector or uiautomatorviewer and mark down all the needed id, name and XPath values you’ll be using. This way you’re not limited to using the Appium Inspector or uiautomatorviewer at the time you’re actually writing your scripts. A correctly gathered library should be easy to check elements from and copy to your scripts as needed.
For example in our BitbarSampleApp, you’ll have several UI elements as radio check buttons, input boxes and a couple of buttons. When you click through any of these UI elements in your own app, you’ll get to see the details of that app and can pick those for your test script. On the picture above, XPath could be easily fetched and the test script could be formulated as follows:
WebElement appUI = driver.findElement(By.xpath("//UIAApplication/UIAWindow/UIAButton")); TouchActions simpleClick = new TouchActions(driver).tap(appUI); simpleClick.perform();
Using gestures with Appium is relatively easy. For example this used
TouchActions objects can contain several events:
press, release, moveTo, tap, wait, longPress, cancel and perform.
Use Local Appium Server for Acceptance
This should be a given, but worth noting in any case. Using a local Appium server with a local test device is always the fastest way to tweak and confirm your scripts. When you confirm that your test scripts work fine on a local setup, do check that you have desired capabilities configured properly for the test run on the cloud, and it’s also recommended to add some basic logic to find readily available device for your test.
In order to launch Appium server use the
appium.js script that can be found in the
bin directory to start the server up. For iOS you should add the
--udid flag to the server, or with the
udid desired capability. Note that if your application is already installed on devices where you’ll be testing your scripts out, you can also give it a bundle ID. For example:
desiredcapabilities.bundleId = 'com.bitbar.testdroid.BitbarIOSSample';
In order to get simultaneous test runs on several devices, you can start up multiple instances of Appium server that all use different ports. With multiple simultaneous devices in use at the same time, you need to set
--port flag for the actual Appium port (default is 4723) and a
--bootstrap-port for communication with the different Android devices. Furthermore, Selendroid and ChromeDriver also need their dedicated ports when automating multiple devices so don’t forget to set
Xcode itself limits the use of multiple devices at the time (there is no limitation on the number of concurrent devices on Bitbar Testing) in a local environment. One single host machine can host only one iOS device per time.
Make Sure the Tested App has All That You Need
This isn’t an easy thing to affect on, but sometimes the apps you need to test might be lacking something on the UI side for you to make well-designed scripts.
It might be easy for developers to slack on giving unique ID’s and descriptions, attributes, and names to elements, but it can at the same time be a real pain for the Quality Assurance and testing folks. Depending on XPath values isn’t always the best way to go either, since the index numbers may change depending on how the app behaves in different situations – or – even when the app is further developer, new UI elements are introduced and those test scripts still rely on indexes given in the earlier phase of the test script creation.
This is a common issue, but it can be nicely and soundly fixed by using Appium Inspector to go through those elements before you start hammering your tests on real devices in the cloud.
If you have a chance to affect on securing the naming of the UI, you should take it. One thing to note also is that on Android SDK the resource-id is something that exists only from API level 18 and upwards. If you need to test on devices on older Android version than that, you cannot depend on resource-id. You’ll have to do with the other UI element values on older OS.