TDD Is Great! But Only When Done Right...

Test Driven Development (TDD) and its closely related kin Behavior Driven Development (BDD) are relatively new kids on the block (only a few years old) and are taking the testing world by storm. Why? Because they are logical, simple, place testing into the proper part of the development schedule, and allow us to verify our applications performance.

Unfortunately, they are not being taught properly.

LEARN TO DO TDD & BDD PROPERLY

When you read a blog entry or book that describes TDD or BDD, they typically use a phrase like "First write your test, then code to pass the test". That's fine, but it's only a partial solution.

Why is it only a partial solution? Because if you do thus, you are only testing the Sunny Day Solution. You need to test the Rainy Day Solution as well. If you don't know what the difference between the Sunny and Rainy Day Solutions are, you don't properly test your systems. Don't feel bad if you're in this category. Most developers and even large development teams don't test their software properly.

So what do I mean when I say test the Rainy Day Solution? Let's examine this in terms of a system I put together in 2002. In 2002, I led a small team as we implemented an NFS front end to a database backed file server. In all respects it was a normal NFS server, except for storing it's file index in a mysql database.

So let's look at how TDD (or BDD) would be used for this (paraphrasing the common TDD example of an object contains a value)

1) Define my test.

Ok. The test defining the requirement is that all file requests have a file name. (code is left as an exercise for you based on your favorite tool)

2) Now write the code to pass the test.

...
FileRequest fileReq = channel.receive();
If (fileReq.fileName == null) {
throw new FileNameMissingException();
}
....

Great. We've written our code to pass the test and throw an exception if we don't pass.

But what is a valid file name? If you read the NFS spec carefully, a valid file name can be a zero length string. Not typically something that would ever be touched in a requirement spec (unless you have a FAT or 8.3 file system).

So the problem is that it's not enough to just write the Sunny Day case, but you need to define and test all cases. Now before you start thinking this is impossible, you need to recognize this is a finite set of tests over 99.9% of the time. If you add bounds, format, and Magic Value testing to your requirement test, you have 99.9% of the teats for your requirement.

So don't just wrote your code to match your requirement test as TDD (and BDD) teaches. Build your full set of tests for good and bad situations, then write your code.