On Oct 11, 2008, at 7:41 AM, ae1fric wrote:

> I'm considering switching my development over to Python under
> Apple's Xcode development
> environment -- Cocoa and Core Data provide some significant
> advantages for the type of
> development I'm doing. The one downside so far is that I haven't
> been able to figure out how
> to do TDD under Xcode.
>
> Has anyone successfully developed with TDD under Xcode?

Yes, there are actually quite a few people who do extensive TDD on Mac
OS X using Cocoa and Xcode — it turns out that it's actually a great
platform for doing so, thanks to its objects-all-the-way-down (for the
most part) design.

Disclosure: I work on the Xcode IDE at Apple, but I don't speak for
Apple or the Xcode team here or anywhere else online. (Unless you
happen to be watching me in a WWDC video...)

> I think the reason I'm struggling to see how to do TDD under Xcode
> is that the development
> environment does so much automagically: you define your data model,
> draw your user
> interface, define bindings between the data model and the UI and
> suddenly you have a
> working application, without writing a line of code.
>
> Any suggestions for using TDD in this kind of environment would be a
> great help.

You can actually still do TDD by writing unit tests that specify how
your data model should be set up, and how the connections between
objects in your nib files -- whether those connections are target-
action, outlet or binding connections -- are set up.

Virtually everything that Xcode, Interface Builder and Cocoa let you
do graphically can also be done in code. None of them *generate* code
to do so, but the objects that are created are the same either way, so
you can just introspect them.

For example, lets say you want to create a View Controller that has a
Name field for an employee, which is managed by an object controller.
You can then write a test that you want the NSTextField's value
binding to be connected to the "selection" controller key path and
"name" model key path of an Employee Controller.

Here's an Objective-C test method that does just that written against
Sen:te's OCUnit framework that's included with Xcode. Using PyObjC
and a Python testing framework should be the similar except for the
obvious differences in syntax and setting up your own type of test rig.

// This assumes viewController has nameField and employeeController
properties for
// the appropriate IBOutlets, and is configured in -setUp
- (void)testNameFieldBoundToName {
NSDictionary *info = [viewController.nameField
infoForBinding:NSValueBinding];
STAssertNotNil(info,
@"The name field's value should be bound.");

NSObjectController *observedController = [info
objectForKey:NSObservedObjectKey];
STAssertEquals(observedController,
viewController.employeeController,
@"The name field's value should be bound to the employee
controller.");

NSString *observedKeyPath = [info
objectForKey:NSObservedKeyPathKey];
STAssertEqualObjects(observedKeyPath, @"selection.name",
@"The name field's value should be bound to the 'selection'
controller key "
@"and 'name' model key of the employee controller.");
}

I've usually created my own assertion macros to encapsulate this kind
of test, of course; then the test winds up looking like this:

- (void)testNameFieldBoundToNameWithBindingAssertionMacro {
MyAssertObjectIsBoundThroughKeyPath(viewController.nameField,
NSValueBinding,
viewController.employeeController, @"selection", @"name",
@"The employee name field should be bound to the employee
controller.");
}

Note that this isn't specifying the layout of the text field in my nib/
xib file, its font, or anything like that. You can specify those in
tests too, if you want to, but you don't have to. Whether you do so
or not depends on the level of detail you need for your UI and the
level of churn that it's likely to go through.

For example, if you're changing the look and feel or layout of your
UI, you might not want to specify any of that, but the above test
would probably be very useful in ensuring you don't forget to bind up
a text field you've just replaced as part of iterating on your UI
design.

On the other hand, I wrote some code a while back to create a "glass
bar" like at the bottom of the message list in Mail.app on Leopard. I
actually did write tests to specify the layout of that interface down
to the point, despite creating it in Interface Builder, because it
needed a very specific layout and I didn't want to accidentally change
it as I adjusted other things in the xib.

One other thing this doesn't do is "push" events through controls to
test that your controller-level code reacts to them. In general you
don't need to write such tests except for your own custom controls.
Otherwise, you can trust that controls will work correctly as long as
they're connected correctly, and just verify that those connections
are set up right in your tests.

The same philosophy can be followed when writing tests that describe
your data model. An NSManagedObjectModel can be loaded
programmatically and you can just ask for its entities and their
properties, and walk across the entire thing looking at their values
in code. That makes it very easy to TDD because you can just create
an infrastructure of tests that say "this model should have an entity
named Employee" and "the Employee entity should have a required name
attribute" and "the Employee entity should have a to-one 'department'
relationship to the Department entity, with an 'employees' inverse
relationship."

Here are some of the blog posts I've written on the topic of writing
tests for Cocoa over the years:

Xcode: Unit testing Cocoa frameworks
http://chanson.livejournal.com/119303.html

Xcode: Debugging Cocoa framework unit tests
http://chanson.livejournal.com/119578.html

Xcode: Unit testing Cocoa applications
http://chanson.livejournal.com/120263.html

Xcode: Debugging Cocoa application unit tests
http://chanson.livejournal.com/120740.html

Trust, but verify.
http://chanson.livejournal.com/118380.html

Unit testing Cocoa user interfaces: Target-Action
http://chanson.livejournal.com/148204.html

Unit testing Cocoa user interfaces: Cocoa Bindings
http://chanson.livejournal.com/172390.html

Unit testing and Core Data
http://chanson.livejournal.com/115621.html

My blog's "unit testing" tag
http://chanson.livejournal.com/tag/unit+testing

Erik Doernenburg, the creator of the useful OCMock mock-objects
framework, has also written a bit about how to use OCMock to test
Cocoa controllers.

Testing Cocoa Controllers with OCMock
http://erik.doernenburg.com/2008/07/testing-cocoa-controllers-with-ocmock/

His approach is very appropriate for testing that your own controller
objects react to changes in your UI correctly, again without having to
"push events" through controls.

Let me know if there's anything else you'd like me to write about!

And if there are any ways you'd like to see Xcode, Interface Builder,
or Cocoa improved, or if you run into any bugs or other problems,
please file an enhancement request or bug report at http://bugreport.apple.com/
— bugs and feature/enhancement requests go into Apple engineering's
Radar system and are evaluated by engineering and management. Even
"duplicate" bug reports are extremely useful because they can wind up
having the critical nugget of information that is needed to fix a bug
(by making it reproducible or revealing a common thread), or can be
used to gauge demand for specific kinds of enhancement.

-- Chris



[Non-text portions of this message have been removed]