Unlike Bill, whose reference to unit testing in Xcode 3.0 is linked at the title, when I started writing unit tests for my Cocoa projects I had no experience of testing in any other environment (well, OK, I’d used OCUnit on GNUstep, but I decline to consider that as a separate environment). However, what I’ve seen of unit testing in Cocoa still makes me think I must be missing something.
The first thing is that when people such as Kent Beck talk about test-driven development, they mention “red-green-refactor”. Well, where’s my huge red bar? Actually, I sometimes write good code so I’d like to see my huge green bar too, but Xcode 3.1 doesn’t have one of those either. You have to grub through the build results window to see what happened.
Sometimes, a test is just so badly broken that rather than just failing, it crashes the test runner. This is a bit unfortunate, because it can be very hard to work out what test broke the harness. That’s especially true if the issue is some surprising concurrency bug and one test breaks a different test, or if the test manages to destroy the assumptions made in -teardown and crashes the harness after it’s run. Now Chris Hanson has posted a workaround to get the debugger working with a unit test bundle target, but wouldn’t it be nice if that “just worked”, in the same way that breaking into the debugger from Build and Run “just works” in an app target?
