Book Review: Test-Driven iOS Development

Test-Driven iOS DevelopmentIt’s not often that I make spur of the moment book purchases, so when I do, it’s a pleasant surprise when they turn out to be gems. The book I purchased on a whim is “Test-Driven iOS Development” by Graham Lee, and it turned out to be one of those “right place, right time” purchases.

I’ve been trying to seriously adopt a test-driven approach to my development projects for a while, but it never really stuck. And though I’d read the standard books on the practice, I still couldn’t get past the seeming futility of it. I know I’m not alone. Most developers philosophize about the merits of test-driven development, but not as many actually implement it, and fewer still on the iOS platform.

It’s hard for me to gauge whether Graham Lee actually brings something new to the discussion, beyond the iOS details, but something clicked for me when I got through this book and then started implementing some of his techniques in my work. I currently work on a project where one group does server code, a developer might do UI code and another write the code that makes REST service calls. These tasks are often done independently and at different times, so I might need to write iOS code to make service calls long before the server folks have a chance to write their end. It’s in this environment that I realized how valuable a test-driven approach could be.

Anyway, back to the book.

The opening chapters begin with the basics of unit testing: what is it, how to write one, and tools you can use. Xcode offers OCUnit, and that forms the basis of most of the book’s code, but the author also mentions other tools that can make your life easier.

The meaty part of the book begins in chapter 5, as an example app is described. The detailed test-driven development gets going from chapter 6 through 9, in which the author steps through every step of the process from data models, app logic and finally UIViewControllers. What I really loved about this book was the lack of magic “hand-waving”. He doesn’t do something really basic and leave you stranded when you actually try a real world task. Every part of the app is developed in the book and many of the gotcha moments are described and solved as the book progresses. Chapter 10 wraps up the project, filling in some missing spots, and then the final chapters address related issues like applying TDD to legacy code, and cutting edge techniques like Behaviour-Driven Development.

I was excited to see some of the advanced techniques Graham Lee offers in this book for testing objects. He explains how to use method swizzling in Objective-C to swap in your own implementations for existing behaviour, and using associative references to add bits of information to objects to assist in verification. I’ve used these techniques to write some cool unit test code now.

Aside from the technical knowledge I learned from this book, the biggest take-away for me was a shift in my concept of why I should be writing TDD code. It’s not just to test and verify code works. That’s important, but your unit tests also describe how your code should behave. This becomes important when you pass your isolated set of classes to another developer to use. Your unit-tests become a gold mine of information on how to use the code you just wrote.

I highly recommend Test-Driven iOS Development to all iOS developers. It will make you a better person.

Adding Array Subscripting To Your Classes in Objective-C

Xcode 4.4 added some great new literals syntax for collection classes and numbers, so now you can write NSArray *array = [@”one”, @”two”, @”three”]; And you can access those elements with array-style subscripting like this NSString *s = array[1];

On it own, that’s great, but there’s more under the surface here. When you write array[1], the compiler translates that into a method call named objectAtIndexSubscript:, which is implemented by NSArray. The cool part is that you can implement this method in your own classes, and then use subscripting on instances of your classes. You can also implement the sister method: setObject:atIndexedSubscript: to set values.

The code below is a simple example of how you could use this:

// Header

@interface ItemCollection : NSObject

@property (strong) NSMutableArray *list;

// Suport for Array-style subscripting. Ex. items[4] = @”hello”;

– (void)setObject:(id)anObject atIndexedSubscript:(NSUInteger)idx;

– (id)objectAtIndexedSubscript:(NSUInteger)idx;


// Implementation

@implementation ItemCollection

– (void)setObject:(id)anObject atIndexedSubscript:(NSUInteger)idx {

self.list[idx] = anObject;


– (id)objectAtIndexedSubscript:(NSUInteger)idx {

return self.list[idx];



// Using the class

ItemCollection *items = [ItemCollection new];

items[1] = @”boo”;

This is a contrived example, but with some imagination, you could find some cool uses for this to make your code more concise. Not only is this available for arrays, but you can use the key-value methods used by NSDictionary as well – objectForKeyedSubscript: and setObjectForKeyedSubscript:

You can read more about this here: