The last few days I've blown the dust off of a prototype and gotten it up-and-running again to discover that it's embarrassingly buggy. In fact, as I've been trying to resurrect the project I've been spending more time fixing bugs than making it cooler. One bug in particular I was having trouble reproducing the situation in which it occurred. And then I thought -
Maybe this is a good time to try out Noel Llopis's free unit test framework!
I made this decision around 7:30 tonight. Since then, I downloaded the stuff, compiled and ran the sample, got it working with my project (which required seperating most of my game code into a static library, a surprisingly painless task - that would have really kicked my ass ten years ago), wrote the code to set up the situation I was trying to repro (laced with CHECK() statements), and wrote the test.
Voila. My fix worked.
But is it fixed in the wild? I can't be 100% sure, but the code isn't *that* crazy, so I'm confident.
So this was all done before 10:30. Three hours. And now I have a testing framework. One of the things I resurrected with the project was its old testing framework...which didn't compile. (I found a note on my buglist: "Unit testing framework should actually...work.") So, going forward, I'm going to give test driven development a try.
I haven't had the greatest luck with unit testing in the past. I've even mentioned it before. It's not one of those cut-and-dried things, like source control or bug tracking software where once you implement it you wonder how you ever lived without it. For me, at least. Even on Clinton Keith's webpage he mentions that velocity went down when they implemented it. In theory, it will pay for itself in the back end. In theory, I will get my prototype to the point where I'm spending more time making it cool and less time fixing legacy bugs. I sure as hell hope so, because the bug-fixing part of making a prototype is no fun.