Subscribe to
NSLog(); Header Image

My Take on Unit Testing

Wil Shipley is getting a bunch of flak for saying "Unit Testing is shit" (paraphrased, but pretty close).

My take: Though we didn't employ much unit testing on any Freshly Squeezed Software products, I do feel that unit testing is great for libraries and other non-UI pieces of software, including the non-UI portions of any application.

Wil's stirred up the broth a bit, and perhaps that was his intent. Perhaps he wanted to hear why he was wrong. But at the same time, I doubt he's likely to change. In the world of competitive "shareware" (or whatever it's being called these days), one thing you need to do is be nimble. Unit testing a largely GUI-driven application is not likely to help you move quickly, release products quickly, and so forth. Classes like NSArray and whatnot have been thoroughly tested by Apple and, so long as you aren't stupid with what you put in and how you use the NSArray (et al.), you can be reasonably safe from unusual crashes that unit testing would have found.

I say reasonably safe, because on the scale of "what's important to the end users versus how much time will it take us to fix it," the bugs unit testing would find that user testing wouldn't find were in the wrong portion of the graph.

So, here it is: unit testing is good, but it may not be a necessary step for some companies, people, or products while for others, it's invaluable.

2 Responses to "My Take on Unit Testing"

  1. I'd say that's a fair take. I'll have more to say on my own blog, maybe tomorrow.

  2. Others (i.e., Wil) can do what they want, but I have gotten to the point where writing a test is like putting on a seat belt. Sure, I can go without one, but I can't feel truly comfortable if I'm not using one. And as with putting on a seat belt before putting the car in gear, I find it just easier to write a test before implementing a method. Mainly that's because writing the tests helps show what the code will look like "in action", i.e., what name/signature/return value is most appropriate to the actual intended use of the code. Not sure how to relate that aspect to a seat belt, though.