Successful first baby steps with Test Driven Development

I’m close to finishing up some work on one of my first true TDD projects and it has gone great for the most part. It did take a long time to get started though. The hardest part for me was fighting the urge to just open the designer and start dropping controls. Visual Studio really does guide developers towards a designer-centric approach which, after having done this for a few years, is very hard to resist. What I ended up doing was thinking about the problems that this application was going to solve and starting there. Make your tests define the problem area and move outward. The idea is that, if you can’t write your tests that show what your code will do, are you even ready to write the code yet?

I was able to get my first few tests out quickly, but then I hit a block where I struggled with the structure I wanted to follow. This turned out to be good because, instead of coding something up that was substandard, I was able to fight through this struggle and come out with a better solution in the end. In doing this, I discovered a great benefit that TDD provides - you can continue coding even if you don’t know all of the answers to all of the problems that your application will solve. For example, I’m still not sure what file format I’ll be using in my application (or even if I’ll use the file system). It really doesn’t matter, though, because I was able to set up an interface and mock that dependency out in my tests and continue with the rest of my application. Had I started with the designer, I likely would have sat around until I had hashed out the file format requirements.

Once I got past my initial hang ups, I was able to fly through the rest of the code. What is even better is that I feel a huge amount of confidence in this code - code that still has no UI around it. I haven’t felt this good about code quality in, well, ever.

If you’re wanting to start with TDD, I’d like to recommend a few resources. First, read more code. If you aren’t using it yet, go get TortoiseSVN and pull down some open source code. The Rhino.Commons repository is an excellent source of code (as well as great utilities). I can also recommend Jeremy Miller’s StoryTeller code. I don’t do anything with FIT tests, but the code is still a great example of WinForms code driven by tests.

Another great resource is screencasts. Watching someone write their tests first helps immensely. Evan Hoff has a great screencast on TDD. It also shows some of the power of ReSharper.

One final thought for this post is something that Bob Martin spoke about in this Channel 9 interview on programming discipline. Bob pointed out that few disciplines are as fragile as programming is. For example, if even one bit is off in your application, it has the potential to crash. One example of a profession that is also fragile is accounting. If one digit is off in the wrong spreadsheet, the CEO of a corporation can get thrown in jail. The way that the accounting profession has solved this is by entering their numbers twice - with credits and debits. If something gets entered wrong, it won’t balance. When the sheets balance, there is confidence in the reported numbers. In the same way, TDD and unit tests provide the balance and confidence that applications are doing what they were intended to do.