Unit Testing outside my comfort zone

I have decided to have a go at writing an app for the iPhone with my new-found free time. It is a platform I haven’t written for before so it’s a nice opportunity to delve into some technologies that I am not very familiar with. First on the list is choosing which language/environment to write my application in. Given the app I have in mind will need to talk to a physical sensor plugged in to the dock connector, I am going to need access to native APIs. So, after briefly flirting with Appcelerator’s Titanium and discounting MonoTouch as I don’t know C#/.NET either, I have settled upon getting to grips with Objective-C and XCode.

I have not written anything in C/C++ for over ten years, which means I have essentially forgotten what little I knew. That’s not a problem, so the best place to start I thought would be Apple’s developer documentation. Let’s start with the good news. These documents appear to be put together really quite well. They’re structured for people new to both iOS and Objective-C development, as well as having links off to XCode docs in relevant places. This is a good thing. Their hand-holding tutorials have got me up to speed with at least getting a bare-bones single-screen application up and working and the language tutorial has given me a sense of the key differences between Objective-C and Java (ugh, memory management).

What is astonishing, though, is the way that unit testing seems to be an afterthought across the board. Of the three Objective-C books I flicked through in Foyles the other day, not one of them even mentioned unit testing. That is including a book specifically targeting Java programmers looking to convert their existing knowledge. Apple’s own iOS Development Guide at least covers unit testing in chapter 7 of 10 and there is a small XCode Unit Testing Guide in Apple’s online documentation. These are OK as far as they go, and they have at least got me as far as getting my first tests up and running, but none of this suggests that unit testing is anything like as ingrained in the development process as it is with my Java experience. There certainly doesn’t appear to be any expectation that you’ll be doing anything as silly as writing your tests first.

XCode itself underlines this. Yes, unit testing is possible, but it just doesn’t feel as ingrained or as natural as with either Eclipse or IDEA. Take this as an example. Here is the first failing test, exactly as prescribed in chapter seven of the iOS Development Guide.

XCode Build Results window showing a failing test

Wait, two errors? But I’ve only written one test! That’s because XCode is reporting the return status of the shell command as a failure, too. Have a look at a fragment of the expanded output from the first error.

XCode Build Results window showing expanded failure message

Even a passing test suite is a little disappointing - you need to drill down into parsed console output to see what went on.

Is it just me, or is that a little dumb? It is what you would put up with in a third-party plugin that was thrown together quickly, or for a little-known tool, but for something as fundamental as unit tests? Really?

comments powered by Disqus