Database Reference
In-Depth Information
if ([detail.outputView.text length] > 0) {
break;
}
}
STAssertTrue([detail.outputView.text length] > 0,
@"Detail view is blank");
}
@end
As opposed to the arcane UIAutomation framework, this is pretty straightforward. In
the setup for each test, we grab a handle on the application delegate. Then in the first
test, we check to make sure that we can find the root view controller—and if we're
running in iPad mode, that we can find the detail controller.
In the two meaningful tests, we set the text of the output view to empty, then trigger
the event handler for the button (which simulates the action of pressing the button
itself). In order to let the asynchronous network request run, we go into a loop, giving
the current run loop a second to execute, then checking to see if the output view has
been set. If we see it is set, we break out of the loop. After the loop ends (one way or
another), we test to see if we got a result.
This style of testing is much easier to create, and can be incorporated directly into the
development process, rather than requiring the developer to break out into JavaScript
to create the UI tests. It will also allow code coverage of UI testing.
The one current problem with UI OCUnit testing is that no one has figured out how
to run it from the command line, so it can't be used as part of an automated build
process. Because it uses the simulator, this will be a fragile thing even if it is enabled,
because the simulator can get into funny states or hang. But even in its present state, if
it continues to work, it represents a big step forward for the testing process.
Now that our app is all tested and happy, we're ready to put it up for sale. But if this
is the first time you've thought about the iTunes store, you're in for a rude surprise.
You need to be thinking about it from the first day of your project, which is just what
the next chapter is about.
