![[info]](http://l-stat.livejournal.com/img/userinfo.gif){kind=small}
Among other hurdles, to properly use Cocoa bindings in your own applications, you need to ensure that the code you write properly supports key-value coding and key-value observing. However, since the release of Mac OS X 10.4 Tiger, the necessary APIs have been available to easily do test-driven development of your application's use of Cocoa bindings, following a trust, but verify approach. (It's also been quite easy from the start to test your support for key-value coding and key-value observing, to ensure that your code meets the necessary prerequisites for supporting bindings. I can write more on this topic in another post if anyone is interested.)
The key to writing unit tests for Cocoa bindings is the
-infoForBinding: method in AppKit's NSKeyValueBindingCreation informal protocol. Using this simple method, you can interrogate any object that has a binding for all of the information about that binding! It simply returns a dictionary with three keys: NSObservedObjectKey, which is the object that the binding is bound to;NSObservedKeyPathKey, which is the key path that is bound — in Interface Builder terms, this is the controller key path combined with the model key path, with a dot in between them; andNSOptionsKey, which is a dictionary of additional binding options unique to the binding. These are all of those additional checkboxes and pop-ups in the Interface Builder bindings inspector for setting things like a value transformer.
<AppKit/NSKeyValueBinding.h> and are documented, too!Let's take a simple example, like the one in last year's target-action example, of a window controller whose window has a static text field in it. The field should have its value bound to the name of a person through an object controller for that person. Assume that I've already created the test case and set up some internal methods on my window controller to refer to the contents of the window via outlets, and to load the window (without displaying it) in
-setUp just like in the target-action example.First, to see that my text field has a value binding, I might write something like this:
- (void)testPersonNameFieldHasValueBinding {
NSTextField *personNameField = [_windowController personNameField];
NSDictionary *valueBindingInfo = [personNameField infoForBinding:NSValueBinding];
STAssertNotNil(valueBindingInfo,
@"The person name field's value should be bound.");
}Let's check the object and key path for the binding.
- (void)testPersonNameFieldHasValueBinding {
NSTextField *personNameField = [_windowController personNameField];
NSDictionary *valueBindingInfo = [personNameField infoForBinding:NSValueBinding];
STAssertNotNil(valueBindingInfo,
@"The person name field's value should be bound.");
NSObjectController *personController = [_windowController personController];
STAssertEquals([valueBindingInfo objectForKey:NSObservedObjectKey], personController,
@"The person name field should be bound to the person controller.");
STAssertEqualObjects([valueBindingInfo objectForKey:NSObservedKeyPathKey], @"name",
@"The person name field's value should be bound to the 'name' key.");
}- (BOOL)object:(id)object shouldHaveBinding:(NSString *)binding
to:(id)boundObject throughKeyPath:(NSString *)keyPath
{
NSDictionary *info = [object infoForBinding:binding];
return ([info objectForKey:NSObservedObjectKey] == boundObject)
&& [[info objectForKey:NSObservedKeyPathKey] isEqualToString:keyPath];
}
- (void)testPersonNameFieldHasValueBinding {
NSTextField *personNameField = [_windowController personNameField];
NSObjectController *personController = [_windowController personController];
STAssertTrue([self object:personNameField shouldHaveBinding:NSValue
to:personController throughKeyPath:@"name"],
@"Bind person name field's value to the person controller's 'name' key path.");
}NSValueTransformerNameBindingOption key in the binding options dictionary returned for NSOptionsKey.You can even extract these kinds of checks into your own subclass of
SenTestCase that you use as the basis for all of your application test cases. This will let you write very concise specifications for how your user interface should be wired to the rest of the code, that you can use to just walk through Interface Builder and connect things together — as well as use to ensure that you don't break it accidentally by making changes to other items in Interface Builder.This is the real power of test-driven development when combined with Cocoa: Because you can trust that the framework will do the right thing as long as it's set up right, you simply need to write tests that specify how your application's interface should be set up. You don't need to figure out how to create events manually, push them through the run loop or through the window's
-sendEvent: method, how to deal with showing or not showing the window during tests, or anything like that. Just ensure that your user interface is wired up correctly and Cocoa will take care of the rest.