It’s really great to see that a lot of people are adopting unit testing for their projects and dramatically improving their quality. Test-driven development and agile development methodologies built around it are really taking off. However, a lot of people still feel that their user interface is difficult to test through code, and either requires a capture-playback tool or requires a different design approach based heavily on interfaces/protocols to get right.
In last year’s post Trust, but verify. I tried to dispel some of the mystery of testing your application’s user interface when using the Cocoa frameworks. However, I’ve still had a lot of (entirely well-justified!) requests for examples of how to put it into practice. So here’s a simple example of what I’d do to write a unit test for a button in a window that’s supposed to perform some action.
First, when implementing my window, I’d follow the standard Cocoa pattern of having a custom NSWindowController subclass to manage my window. This window controller will have an outlet connected to each of the views in the window, and will also wind up with a private accessor method — used only within the class and any subclasses, and in testing — for getting the value of each of its outlets. This design flows naturally from the test which I would write to specify that the window should contain a button. First, here’s the skeleton into which I’d put tests:
// TestMyWindow.h
#import <SenTestingKit/SenTestingKit.h>
@class MyWindowController;
@interface TestMyWindow : SenTestCase {
MyWindowController *_windowController;
NSWindow *_window;
}
@end
// TestMyWindow.m
#import "TestMyWindow.h"
#import "MyWindowController_Private.h"
@implementation TestMyWindow
- (void)setUp {
// MyWindowController knows its nib name and
// invokes -initWithWindowNibName: in -init
_windowController = [[MyWindowController alloc] init];
// Load the window, but don't show it.
_window = [_windowController window];
}
- (void)tearDown {
[_windowController release];
_window = nil; // owned by _windowController
}
@end
That’s the infrastructure into which I’d put my other test methods for this window. For example, I’ll want to specify the nib name for the window controller and ensure that it actually knows its window:
- (void)testNibName {
STAssertEqualObjects([_windowController windowNibName], @"MyWindow",
@"The nib for this window should be MyWindow.nib");
}
- (void)testWindowLoading {
STAssertNotNil(_window,
@"The window should be connected to the window controller.");
}
Now let’s check that I have a “Do Something” button in the window, and that it sends an action directly to the window controller.
- (void)testDoSomethingButton {
// _doSomethingButton is a private method that returns the button
// conected to the doSomethingButton outlet
NSButton *doSomethingButton = [_windowController _doSomethingButton];
STAssertNotNil(doSomethingButton,
@"The window should have a 'Do something' button.");
STAssertEqualObjects([doSomethingButton title], @"Do Something",
@"The button should be titled accordingly.");
STAssertEquals([doSomethingButton action], @selector(doSomething:),
@"The button should send -doSomething: to its target.");
STAssertEquals([doSomethingButton target], _windowController,
@"The button should send its action to the window controller.");
}
You’ll notice something I’m not doing in the above: I’m not simulating interaction with the interface. This is the core of the trust, but verify approach to unit testing of your user interface.
I can trust that as long as I verify everything is hooked up properly that Cocoa will cause the button to send its action message to its target — whether it’s a specific object or, if the target is nil, the responder chain — whenever the button is clicked while it’s enabled and not hidden. I don’t need to simulate a user event, and I don’t even need to display the interface while running the unit tests. All I need to do is inspect, through code, that everything is wired up correctly.
Note that I can do way more than the above in testing my interface design, too. For example, I can ensure that the control layout is correct according to what my interface designer has specified, by checking bounding rectangles for example. But testing only the functionality of my interface has significant advantages, too. For example, it doesn’t matter if I wind up using a custom kind of button to achieve exactly the kind of look and feel or behavior I need. It doesn’t matter if I wind up changing the layout in response to feedback. No matter what I do, I’ll know that functionality won’t accidentally break while I’m messing around in Interface Builder — even if I completely rip out my interface and replace it with a new one!
This approach can also be used for testing Cocoa bindings using the -infoForBinding: method that was introduced in Mac OS X 10.4 Tiger. I hope to write up a post soon on how to approach Cocoa bindings using these same techniques, but it should be fairly straightforward given the above and the above documentation.
Update: I’ve struck through the check of the button’s title above, because you may or may not want to do that. For example, if you’re primarily running your unit tests against your development localization, you may want to put it in. But if you want to run your unit tests against a localized build of your application, you’ll probably want to avoid checking a localized title against an English string. A “have your cake and eat it too” strategy might be to keep a variable somewhere in your application that can be used to selectively disable checks of only localized strings.
Update July 7, 2007: I’ve finally written a post, Unit testing Cocoa user interfaces: Cocoa bindings, on how to write tests for Cocoa bindings. Now there’s no excuse for not doing test-driven development of your Cocoa user interfaces!