Debugging iPhone application unit tests

I’ve been learning a whole raft of new things lately as I get back into developing for the iPhone in earnest. There is a series of blog posts I’ve been planning on setting up Continuous Integration and Test Driven Development for iPhone applications. However, this post is more of a “where I’ve got to so far” with unit testing with iPhone development and a quick plea for information if you have anything to add.

It would seem that the XCode unit testing story for iPhone apps is half complete. If you follow the guidance in Apple’s official documentation, then you can add a new Unit Test Bundle to your XCode project. This can be attached to the main App Target so that unit tests run each time you build. The bit that is missing is the ability to easily debug these unit tests.

When a unit test fails, you can get a log or error message to try and guide you to understand what failed. There are times though when attaching breakpoints to your application code and stepping through the unit tests allows you to clearly see what’s at fault. With the standard setup, the tests run in a separate script before the Debugger attaches itself to your application code. This means that breakpoints are useless.

I did find an article on ‘How to Debug iPhone Unit Tests’ by Grokking Cocoa which pointed me in the right direction. However the article describes how they set up OTest for debugging which involves 7 or 8 Environment Variables to be set. Even after following the article the iPhone app wasn’t building.

It would seem a simple request to be able to debug unit testable code, coming from a Visual Studio background. At the moment we’re trialling a Google Code project we found called WiteBox. This does work and was relatively easy to set up once we had included the CoreGraphics.framework in the WiteBox target. We also had to edit UITestResultsBar.h to have #import <CoreGraphics/CGContext.h> because it wasn’t building without it.

This solution runs unit tests in the iPhone simulator as an iPhone application. It seems an unnecessary overhead to get test results reported back in the simulator rather than in the XCode IDE. Given the lack of concrete support for unit testing in iPhone development, I can only assume that this is not commonplace amongst iPhone developers at the moment. I, however, realise the benefits that TDD and Continuous Integration brings and will continue to strive to come up with a good setup to avoid future unforseen problems.