Philipps paper equivalent Blog

With the appearance of iOS 4.0 Apple introduced a new Test-Framework for automatically UI Testing: UI Automation. Based on Javascript and build-in into Instruments, UI Automation is a very useful tool during the Developing of iOS Application.

A very good introduction in UIAutomation is here and here.

During the development of a iOS Application, we decided to port it to iOS 4.0 and therefor use also UIAutomation for regression testing (before that we used GHUnit Tests for Component Testing - but thats another story).

As we are primarily a company dealing with web-based application, we had almost zero afford to deal with the Javascript syntax of UI Automation. But we had to deal with the fact, that we developing a dual language Application (de and en), and therefore need a possibility to test the whole UI in both languages.

If you are familiar with UI Automation, you probably know that the Framework uses the accessibility labels of your UI and also often Button Labels. So you have to deal with the actual language of the current UI Setting. But wait. There is already a valid mapping of different language to a given key. If you internationalize your application you will use so called Localizable.strings to do your language Mapping (more here).

So we just need a way to move our already existing Mapping into our UI Automation world. UI Automation supports the import of separate JavaScript Files to use your own Libraries and Settings. So i build a conversation script to translate your different Localizable.strings to JavaScript and moving all languages into one big collection.

So for example a String like this:

    "Library" = "Bibliothek";
    "Shop" = "Kiosk";

Will be converted to:

    UIA.Localizables = {
    "de":{
    ...
    "Library" : "Bibliothek",
    "Shop" : "Kiosk",
    ...
    },
    "English":{
    }
    ...
    }

The next step is to determine during your UIAutomation Test which language Setting you need to Load from your Localization File. It is possible to readout some System Settings during an UIAutomation Test. The basic functions to find your current language and to read the correct language Array look like this:

    UIA.getCurrentLang = function(){
        if(application.preferencesValueForKey("AppleLanguages")[0]  == "en")
            return "English";
        else
            return application.preferencesValueForKey("AppleLanguages")[0];
    }
    UIA.getCurrentLocalizables = function(){
        return UIA.Localizables[UIA.getCurrentLang()];
    }

    var Localizable = UIA.getCurrentLocalizables();

The first function is necessary to capture a quirk of the recent Xcode Versions (some people calling it a bug :-) ).

So now we can just use our String within our Test-Cases.

#import "lib/Localizables.js"

function    delay(seconds){
    UIATarget.localTarget().delay(seconds);
}

function tapTab(name){
    var window = UIATarget.localTarget().frontMostApp().mainWindow();
    window.tabBar().buttons()[name].tap();
}

var window = UIATarget.localTarget().frontMostApp().mainWindow();
tapTab(Localizable['Library']);
delay(1);
tapTab(Localizable['Shop']);
delay(7);

I attached the conversion script to this post. You just need to alter the source and destination folders of your i18n files and the UIAutomation-Tests directory.

Download file

Sometimes it might be useful to have an exact piece of information about what version of an app you have currently running. Especially if you have a decent Testing-Group, it is important to track the versions in which a bug appears. The goal of this post is to achieve a info panel like this in your application. You get the Application version (from the Application Bundle), the Repository Revision and the Date of the last Commit.

Picture 1: Example Application About Dialog

We are using here the build-in functions of subversion to update given keywords with the repository information. More about this topic here. There is also a way to use this method with git, but i did not test it yet. You may find out more about this here

The first step is to create a File-Template you can import in your code, with which you can access all the necessary details:

#define APP_VERSION   \ 
[[[NSBundle mainBundle] infoDictionary]   \  
objectForKey:@"CFBundleVersion"]
#define APP_EXECUTABLE   \ 
[[[NSBundle mainBundle] infoDictionary]   \  
objectForKey:@"CFBundleExecutable"]
#define APP_NAME   \ 
[[[NSBundle mainBundle] infoDictionary]   \  
objectForKey:@"CFBundleName"]
#define APP_BUILD_REVISION @"$Rev$"
#define APP_BUILD_DATE @"$Date$"
#define APP_LAST_AUTHOR @"$Author$"

The next step is to tell Subversion to replace the placeholder with the subversion values. You can do this with setting the subversion keyword for that file. After that, with every commit of the file "version.h" the values will be updated.

svn propset svn:keywords 'Revision Author Date' version.h

The very last step is to make sure, that "version.h" will be updated each time you make a change to your application. Assuming you build your app every time you made a change, you can use the functions, build into Xcode to force an update on "version.h". We use the trick, that every change on the propsets of "version.h" is equal to a file modification itself. So we create a small bash script, setting the propset "build" to a new value. After that, "version.h" needs to be commited as a new version.

#!/bin/sh

DATE=`date`
HOST=`hostname`

svn propset build "$HOST $DATE" Version.h

Now we need to add the run of "buildUpdate.sh" to our Build-Cycle. (Picture 2 & Picture 3).

Picture 2: Project Target Settings

Picture 3: Insert Script Call

After a successful commit, the file "version.h" will look something like this:

#define APP_VERSION   \ 
[[[NSBundle mainBundle] infoDictionary]   \  
objectForKey:@"CFBundleVersion"]
#define APP_EXECUTABLE   \ 
[[[NSBundle mainBundle] infoDictionary]   \  
objectForKey:@"CFBundleExecutable"]
#define APP_NAME   \
[[[NSBundle mainBundle] infoDictionary]   \  
objectForKey:@"CFBundleName"]
#define APP_BUILD_REVISION @"$Rev: 1047 $"
#define APP_BUILD_DATE @"$Date: 2011-01-21 18:53:38 +0100 (Fri, 21 Jan 2011) $"
#define APP_LAST_AUTHOR @"$Author: phaus $"

You might modify the output (e.g. filter out the $s or reformat the date) to get a more stylish output.