Can I interest ma’am in a slice of TDD?

The perception of time passing is a funny thing. It only seems like yesterday that I was still a child and the summer holiday seemed to last a lifetime. And now, here I am somewhat surprised that my complement of fingers and toes are no longer enough to count the years that I have been developing software. In fact, I now need an assistant to contribute two feet and one hand too. Ouch!

Anyway, in all my years of writing code there has been a constant stream of faddy languages, gimmicky ideas, and people making proud announcements that developers are no longer needed due to their revolutionary product that will “virtually write the code for you”.

Needless to say that most have passed on a lot quieter than when they arrived. However, as well as the hot air, there have also been a handful of really simple, yet elegant ideas that have forever changed the way development is delivered. Ideas such as the agile manifesto.

Out of these, if I were to pick the one that has had the biggest impact on my own code, and has also helped me to do the same for client organisations, then it would be Test Driven Development (TDD). For those not already familiar with the term, the basic concept of TDD is that you first write your tests, then develop your code until it passes the test. What could be more simple than that?

In my opinion, if the one improvement an organisation makes is to follow this basic TDD recipe, then the overall quality and reliability of their software will be greatly improved. And as a result, for possibly the first time ever, they will also have the confidence that it actually does what it is supposed to do. Why? Because they can prove it empirically.

However, whilst this will get them a product that does everything they expect it to (or at least, everything the person who wrote the tests expected), it gives them little confidence around anything else. In terms of the Rumsfeldian quadrant, they are only tackling the known knowns, and they are still leaving all the unknown stuff to its own devices. And you know how the devil likes to make work for idle unknowns.

So when I first start working with a development team to fix their security issues, it is common to find their tests are very simple, and mostly focused on proving a desired use case works. Very little thought has been given to the application gracefully detecting and coping with anything else. Which is a bit scary, as for every use case there is an equal and opposite bus-load of abuse cases (figuratively swerving across the central reservation and into oncoming traffic).

I’m already starting to ramble, so I’m going to end here, but before I do I just want to finish up with my top-tips for getting the best from the TDD process:

• Build both use and abuse case tests before writing any actual code. 
• Seek out the most anally-retentive developer on the team, and cajole them into writing (or at least checking) your tests. 
• There are a lot more possible abuse cases than use cases, so if you count your tests and find that you don’t have more negative tests than positive, then you should start suspecting that something is amiss.
• Don’t stop refactoring until all the tests pass.