Test Driven Development

I have been working hard to catch up with the current state of the software industry. One area of interest I have focused on in particular is the art of Agile Software Development. Why haven't I jumped in to the "deep end" of agile before now? Well, for starters, I was completely engrossed in starting and operating a construction company since the beginning of 2004. Before that I only knew a little about Extreme Programming--not even enough to be of use.

So what is agile? It is an umbrella of ideas that covers many different practices and emphasis. It is a way to better serve the customer. It makes the customer an integral part of the development process and keeps the software development cycle accountable. When done well it can save both time and money.

I have been working to learn both the software development and software management parts of agile. Since April I have implemented continuous integration and unit testing into my software craftsmanship process. I have also worked on learning the SOLID principles as well. More recently I have worked to learn the practice of Test Driven Development.

So what is TDD? It is the process of writing the unit test before writing the unit. When done well it serves several purposes: A) It generally produces better test coverage. It is less likely that a unit of code will be written with no tests when the tests are always written first. B) Code will be designed with unit testing in mind. In fact it will become very difficult to write untestable or hard to test software when the unit tests are written first. C) And the unit tests can be written in such a way as to self specify the design of the software. If the tests are written clearly they become the description of how the software is to perform.

For me TDD is a very different way of approaching software development. In the past I would dive into a project thinking about algorithms and implementations. Now with TDD I am having to force myself to think of interfaces and design specifications for my software. But the resulting quality of the software is well worth it.

One final note: I have noticed that TDD requires practice to do well. It may seem to be a slower way to write software in the beginning but the results are worth it. The initiate to TDD must have patience!