Testing Enterprise iOS Applications - Developing Enterprise iOS Applications - page 72

var result =
outputView.withValueForKey(
"Postal Code: 03038\nCity: ... Longitude: 71.30W\n",
"value");
if (result == null) {
UILogger.logFail("Did not get expected result");
}
So what have we got going on here? The UIALogger.logStart call signals to the frame-
work that we're about to start a test. The next two lines are boilerplate, and gain access
to the currently visible window of the application. The logElementTree call is useful to
put in during test development: it dumps a tree view of all the UI elements below the
specified one (in this case, the window) to the log, so that you can figure out how to
navigate to specific elements in your test code.
Next, we get a list of all the toolbars on the window (there should only be one, some-
thing we test for and fail if untrue). We also look for the TextView that we use for
output, and the button inside the toolbar called “Zip Code”. Here we see one of the
weaknesses of the framework—you need to access the buttons by their label text, which
means that these tests will fail if the test is run in a different language. You can also try
to get the button positionally, but this means that if you add a button, the test may
break.
Once the test has access to the button, we have the test tap it, and check to see if the
string placed in the results view is correct. But we can't just tap the button and then
use the value() method on the output view to check it, because the web service will
almost certainly not have returned yet, so the text in the view will be the old text.
Instead, we need to use the withValueForKey method, specifying “value” as the key. The
way that this method works is that it searches for an element which satisfies the criteria,
waiting until a specified timeout (which you can configure) has elapsed before failing
(and returning null). So, if the output view value becomes equal to the test string before
the timeout occurs, the view will be returned and the test against null will fail.
This kind of programmatic acrobatics is typical of what you have to go through when
using the UIAutomation Framework. It is extremely poorly documented by Apple,
tends to be very fragile and occasionally non-intuitive, and is (unfortunately) the only
officially supported game in town.
Anyway, once you have your test script, you fire up Instruments, and select the Auto-
mation template ( Figure 5-7 ). Once at the main screen, use the target pulldown at the
top to select the simulator version of your application build (which may be hiding down
inside of your ~/Library/Developer/DerviedData hierarchy), select the script on the
script pane, and hit the record button ( Figure 5-8 ).
When you run the test, the Script Log will show you the results. One thing that you'll
quickly notice is that the test never stops; you have to hit the record button again to
stop it. For this reason (among others), you can't use these tests from the command
line as part of an automated build process.