Tuesday, July 25, 2006

Some Thoughts on TDD

I'm posting this entry using the Blogger toolbar for Microsoft Word.  If this works, it will make my life a lot easier.  I spent a fair amount of my time in Microsoft Word.

I am a big believer in automated unit testing.  I work in the Microsoft .NET world and I use NUnit all the time.  I have been playing with the concept of TDD, Test Driven Design or Development.  

Like any new concept, TDD plays strange games in my head.  If I understand the concept properly, I should let the design emerge from the tests.  I suppose that that would work if I had not spent a fair amount of time before I sat down to code thinking about the structure for the problem in question.  It is just very odd feeling to pretend that you don't know that you're going to use a particular design pattern, for example, and write tests and code that do not take into account that final destination.  I suppose that, if you take this to its logical extreme, that some other design might pop out in the process and that design might be better.  That is certainly one of the comments that Kent Beck made in his book on the topic.

Anyway, I have a particular project I'm working on.  This is code written by someone else that I inherited and I'm trying to understand what's going on.  The style of the code is quite a bit different from that which I prefer.  It is a Web application with a lot of the business logic in the web pages or in the code behind for the web pages.  I prefer my web pages to be as thin as possible with all of the "meat and potatoes" logic in a separate set of classes (or even separate assemblies).  That way I can create a set of unit tests and run them in a fairly short time to make sure that I've understood was going on.

What I have done with this project is to create a separate assembly with separate classes and I am using TDD to try to capture the essence of the business logic.  I like to have written requirements.  On this project there are almost no written requirements.  For this one application, I decided that I would try to understand what was going on by extracting a set of requirements.  I then started writing unit tests from these requirements and “filling in the blanks” by either writing my own new code or cutting and pasting code from the existing application.  [Right now, I can hear some purists out there who are going "Oh my God, I don't believe he actually said that" but that's the way it is.  I just started this process yesterday and I made some good progress.  I'll let you know how it turns out.


Post a Comment

Links to this post:

Create a Link

<< Home