Test-driven development

There's a fabulously ironical website called Waterfall 2006 - International Conference on Sequential Development (http://www.waterfall2006.com/). For those people who have suffered by waterfall development (either as protagonists or antagonists) it's well worth a read... I particulary like the title of a keynote speech "Put Testing Where It Belongs--At the End" (although technical document writers would possibly argue the point) testing has traditionally been the activity that must be endured once the clever people have had their input (i.e. created the specs and written the code).
As a code-monkey, this resonated with me; and only at a subconscious level did I acknowledge that something wasn't quite right about it. It wasn't until I became the 'Project Manager' - the guy who takes ultimate responsibility for delivery of a solution to a project sponsor, that I *honestly* started to care about the quality of what was being written...

I mean, come on! It compiles, so it probably runs... right? Ummm....

A couple of years ago I heard about test-driven development, and heard that it could increase the quality of developed code; but it was only last month that I actually started using it... It all started like this:
I needed to test some business-critical stored procedures we had written for a new client; They were quite complex, and in order to sign them off as fully functional, we had to check a susbtantial number of things. I didn't want to just run them and check the results.. It would have taken far too long, and I probably would've forgotten something, and I almost certainly would've forgotten to write down the details of what I was checking. So I told the developer I'm working with that I was going to write a program to automatically do the checking for me.
1/2 an hour later, I'd just about conceptualised a front-end in my head; How I was going to enter the tests; run the tests and check the results...
Then he says "You don't need to write a front-end for this testing program, you can just use NUnit..."
(We subsequently decided to use the Microsoft VS 2005 testing suite, but the prinicipal is exactly the same...)

So what is test-driven development? Wikipedia (http://en.wikipedia.org/wiki/Test-driven_development) describes it as "a software development technique that involves repeatedly first writing a test case and then implementing only the code necessary to pass the test"

The key word here, is first You write a test *first*; then you write the method to be tested... this means that when you're writing the actual code, you already have a very real goal to achieve for that small part of the project... you have to make your code pass the test!

There are some excellent articles that explore the 'how-to' side of TDD in greater detail, written by people with a wealth more knowledge and experience than I; (Google 'Test-Driven Development' and have a look...) but I thought it was worth sharing just how amazing the results are; and how much of a difference this can make to the whole software delivery process.

Consider the code behind Project Spaghetti... You know the one(s) I mean... the ones where you're petrified of tugging on this strand of spaghetti over on this side of the plate, because you have no idea how many meatballs are going to fall off the other side! The business says 'I just need that commission calculator to consider price-breaks and bulk discounts'; but you know for a fact that they asked you to amortize commission calculations per product line across months for some product categories and quarter for others... You just got the damn thing working (cos the contractor that wrote the first version was clearly a total bandit, and you definitely wouldn't have written it like that...) and you really don't want to touch it!
Now consider an automated set of tests that, should they all pass, *definitively prove* that the code is still functionally correct... All of a sudden, you're not scared of adding that extra piece of functionality; or subtly changing the funcationality you've got because your business rules just changed... All you have to do is:
- create/alter the test criteria in your unit tests
- Run the new/altered tests; note that they fail...
- Write the new code
- Re-run the tests... And if all of a sudden you're seeing tests failing left, right and centre; then you throw away your changes, and think about how to solve the problem without touching the fragile code in the middle!
But here's the thing... You spotted that you inadvertantly broke something else *before* it went into a production envrionment (and the system users starting ringing helpdesk's phone off the hook) and *without* paying the QA team to perform a month's worth of regression testing...

As a man who seeks the eutopian ideal of delivering perfect software solutions; this really does resonate with me...

For those of you (like, until very recently, me) who have yet to put this time-saving, labour-saving paradigm into practise, remember this... "A dead fish can't swim; But it can float down a waterfall"