Running UIAutomation tests from Command Line

Posted in Apple, iOS, QA, Testing by AltF on February 5, 2012

Continuous Integration (CI) implements continuous processes of applying quality assurance. In the App development world, we can achieve this by automating the build and release with includes automatic trigger of smoke/functional tests and automatic deployment.

I’ve covered how to write UIAutomation tests in my previous posts (here and here) and also how to distribute stable build over the air (here). You can run your tests from command line and configure a hudson job to always deploy stable build automagically. You can run your tests from CLI using the following command.

$ instruments -t templateFilePath targetAppName

By default the tests will be executed on the simulator, you could execute the tests on actual device using the following command:

$ instruments -w deviceID -t templateFilePath targetAppName

You could execute any instruments template using command line, for example to trigger a UIAutomation template from command line you would use the command as follows:

$ instruments -t /Developer/Platforms/iPhoneOS.platform/Developer/Library/Instruments/PlugIns/AutomationInstrument.bundle/Contents/Resources/Automation.tracetemplate <path-to-your-app>/<appname>.app/ -e UIASCRIPT <path-to-your-js-test-file> -e UIARESULTSPATH <path-to-results-folder>

This is really helpful in terms of achieving CI compliance, I’ve basically written a py script that does the following:

– create a new tag from svn trunk with minor release version update
– grab the tag from svn
– complile the app from command line for xocde
– run the uiautomation smoke tests from command line (mentioned above)
– if tests are green, publish the build on the web server for OTA test distribution.
– repeat for new release

iOS Wireless (OTA) App Distribution

Posted in Apple, mobile, QA, Tech by AltF on May 18, 2011

One of the major annoyance of developing a native mobile application for iOS is distributing internal builds to enterprise users/beta testers. Using the ad-hoc distribution method developer has to create a release build (.ipa or .app) with provisioning profile (.mobileprovision) and send both the files to the users who then copies these files to iTunes and syncs their device to the computer. And the users have to repeat this process each time there is a new build.

With iOS 4 you can now have over-the-air installation of applications. You can distribute in-house software to users without have them to use iTunes/Computer. Installing the app is simple. Users download the manifest file from your website to their iOS 4 device, which instructs the device to download and install the apps referenced in the manifest. You can distribute the URL for downloading the manifest file via SMS or email. You can also create a custom, easy-to-remember tiny url ( and share with your users.

It’s up to you to design and host the website used to distribute apps (I use simple touch friendly template for nested list of directories . You need to make sure that users are authenticated, perhaps using basic auth or directory-based authentication, and that the website is accessible via your intranet or the Internet. The app and manifest can be placed in a hidden directory, or in any other location that’s readable using HTTP or HTTPS.

Step 1. Creating the app (.ipa) and the manifest (.plist) file

  • In Xcode, you create an app archive using the “Build > Build and Archive” command.
  • Then, in the Archived Applications source in Xcode’s Organizer, select the app and click the “Share Application…” button.
  • Then click the “Distribute for Enterprise…” button.
  • In the distribution window, enter the title and the full url to the app (.ipa) file (path to the app on your webserver) for example,
  • Xcode will then create the app (.ipa) and manifest (.plist) file based on the information you provided
  • The manifest file is a file in XML plist format. It’s used by an iOS 4 device to find, download, and install apps from your web server.

Step 2. Hosting the files on your web server

  • Along with the generated .plist and the .ipa files, you’ll need the provisioning profile and a simple index file.
  • Create a simple index file with the following href

<a href=”itms-services://?action=download-manifest&url=”>Install app</a>

Note: When you archive using XCode4 + iOS 4.3 you might see “No Packager exists for the type of archive” message in the organizer when you click on share and Distribute for Enterprise option may also be missing in XCode4. This happens when you have some linked projects inside your main project. Go to the Build settings of linked projects and set the setting “Skip install” (Deployment section) to “Yes” (leave the “Skip install” of the main project to “No”). Build and Archive again and you should be able to select the ipa and the identity and when you click next you should see an option to “Save for Enterprise Distribution”

Automating iOS User Interface Testing with UIAutomation

Posted in Apple, mobile, QA by AltF on November 14, 2010

Update: 25 June 2011
iOS 5 now supports recording these user interactions in UIAutomation which means no need to write these scripts manually.

Apple included Automated Testing support in iOS 4.0 which lets you automate testing of your iOS applications by scripting touch events. It allows you to write test scripts to exercise your application’s user interface elements as the application runs on a connected device or simulator. You write the tests in JavaScript to the UI Automation API, which simulates user interaction with the application as it runs and returns log information to the host computer.

In a nutshell:
– Automates UIKit based applications.
– Works on all iOS devices (iPhone, iPod Touch, iPad) and simulator.
– JavaScript automation scripts.
– Integrated in Instruments.
– Accessibility based.

Step 1 – Getting Started.
– Make sure that you have the latest iOS SDK (4.0+) installed | iOS SDK
– Familiarize yourself with Instruments | Instruments User Guide

Step 2 – Preparing your application.
Ensure accessibility is enabled and all the UI controls and views in your application are tagged with unique accessibility labels which makes it easy to access them in our test scripts. Using Interface Builder, you can set an element’s accessibility status and provide custom content for the label.

Step 3 – Writing test scripts.
In essence, your test script is an ordered set of commands, each of which accesses a user interface element in your application to perform a user action on it or to use the information associated within it. All the user interface elements in your application are represented to the script through an ordered hierarchy of objects defined by the UIAElements class and its subclasses.
To reach a specified UI element, the script simply calls down the element hierarchy, starting with the top level target object obtained by calling UIATarget.localTarget() The control hierarchy looks like:

var target = UIATarget.localTarget();
var application = UIATarget.localTarget().frontMostApp();
var window = UIATarget.localTarget().frontMostApp().mainWindow();

For example, if your application has a table view in the main window the hierarchy should looks like:
• Target application ■ Main window ■ View

Similarly, within a view there are elements:
• Target application ■ Main window ■ View ■ Element

And to access the child elements within an element:
• Target application ■ Main window ■ View ■ Element ■ Child element

The Automation instrument maintains a complete element hierarchy that represents your application’s user interface. To view that hierarchy, use the logElementTree method to write an outline of it to the log:

Once you are able to access the elements you can perform various actions on it. I’ll show you how to simulate basic touch events.

Tapping buttons:
Example: If you want to tap on the Add button on the top navigation bar. (Note that the navigation bar is outside the main window, hence we access it via:)

Scrolling to an element:
Example: If your main application is an address book app, with the main window consisting of a tableview with elements in it. You can simply scroll to a particular element:
window.tableViews()[0].scrollToElementWithName("John Appleseed");

You can write a few assertion functions to verify if the expected results matches the actual results. You can log the results based on pass/fail. Simple example:

var testName = "Test Case 1";
UIALogger.logMessage("Assert Text - Check if element 5 is John Appleseed");
var expected = "John Appleseed";
var actual = window.tableViews()[0].cells()[5].elements()[5].name());
if (expected = actual) {
else {

Step 4 – Executing the test.
– Once you are ready with the test script. Compile your app in the debug mode and create a simulator build.
– Launch Instruments and select Automation from iOS Simulator templates.
– Select your target application from “Choose Target” option on the top.
– Select the test script from “Choose Script” option on the left window.
– Hit the red record button once done. It will fire up the simulator with your target app and start executing the tests.

– If you are facing any issues running UIAutomation on the iPad, refer UIAutomation on iPad

API Documentation

Tagged with: , , , , , , ,
%d bloggers like this: