I’m pulling together a presentation on test-driven development for our company’s Java technical community, and so I’ve been forced to look at my own development practices. Sure, I use Ant as a build tool, and even use it to run my Junit tests. In fact, I’m so convinced of the value of this sort of stuff that when I made my brief foray into PHP, I found its corresponding xUnit tool, PHPUnit, and used it to help me build my system. But, casting a critical eye on how I actually do things, I can’t actually call my style of development “test-driven”. Often “test-validated”, and even sometimes tests that are written concurrently with code, but hardly ever test-driven. The idea behind test-driven is that you write the test first, and then your code once you have a test case to validate what you’re writing. My approach generally is to write the code first, and then to not consider it “valid” until it passes a test case that I’ve yet to write. Unless, of course, I consider the code I’ve written either too trivial to be worth testing (danger, Will Robinson!) or too difficult to set up a test case for (holy coding ostrich, Batman!) – in which case, I just sort of cross my fingers and figure that it’d be easier to catch any bugs as we use the stuff than it would be to write the test case to find it at the outset.
I’m not sold yet on TDD. Although I’m a fan of unit testing, my client doesn’t pay me for unit tests, they pay me for a working system (yes, I recognize that there’s a correlation between the two, I just think the correlation is looser than one to one). So, I’ll have to see a clear win in terms of either time required to do initial development, or time required to hunt down bugs. So far, I think I’d spend more time writing unit code than I’d recoup. (Remember, I’m already writing unit code for some things – just not all things.) Although I know there’s flexibility in TDD, that not _everything_ gets tested to the lowest level, seems you’d have a hard time defining where to stop. I’m looking over Kent Beck’s Test-Driven Development by Example book to see an expert walk through the process and make sure that I’m giving the thing a fair shake. May give more room in my blog later to some of the stuff I find out…