TDD experiences

Since early January some of us in my office have been exploring the use of Test Driven Development and it's potential benefits in our development process. I first became aware of TDD several years ago when the idea was just breaking onto the scene of software development. At that time there was very little information and virtually no proof that it brought any benefits to the software development table.

These days the picture is quite different, a simple search in your favorite search engine will turn up many references to TDD, including books, how to's, blog entries, etc. Although it takes some time to get used to TDD, the benefits do begin to show themselves, I had one of these moments recently. Although I've been working with some legacy code which makes using TDD much harder, I've still be able to put in a variety of unit tests. These tests are quite useful as you work with the code because you know very quickly if some existing piece of functionality has been broken. This idea is a staple of TDD, however my experience recently helped enstill this idea.

I was working on an alternate implementation of a class that had a fairly rich set of unit tests associated with it. The changes being made were rather central to the class, so I just went ahead and coded the new implementation. Now, with traditional software development techniques, you would then create some developer tests or run the code through some known conditions to make sure it behaves as expected. This works, but in reality does not provide you with very good code coverage, also, these tests are often thrown away once the initial developer testing is performed, not exactly and ideal situation.

My situation was a little different since there was a rich set of unit tests to measure the state of the code. Once the code was complete, I ran the tests (only took about a second to run them) and voila, immediate feedback on what worked and what didn't. Go back and fix the broken tests, etc. It is quite interesting how positive you feel about your changes when there are a rich set of tests that verify your code. Obviously these tests are not very useful if they take alot of time to run, in TDD, you are encouraged to produce small well defined tests that execute quickly. As mentioned previously, the few hundred tests running against this particular module all run in less than a couple of seconds!

If you are interesting in checking out TDD, check out www.testdriven.com or pick up Dave Astels book, Test Driven Development: A Practical Guide. This book is an excellent start for those looking at TDD and want to know more about it and how it works.