So, a couple of days ago while sitting at the lobby of my hotel for the MVP Summit, I decided to come up with a simple Smart Client shell for the LOB Windows application my company uses.
So there I am minding my own business when along comes Jean-Paul Boodhoo, James Kovacs, David Laribee, DonXML and ask what I was working on. After some explaining of my intentions for replacing our legacy VB6 application with a brand new .NET one, JP couldn't resist the opportunity to do some TDD and Pair Programming.
I must say, that I've always been of the design first, unit test later nature. Why, you ask? Well, I can visualize the approach the solution needs to take quite easily. After I'm done with it, I can then write the unit tests to verify that things work the way I intended for them to work. What I didn't realize is that I used my design as notepad to write down my ideas since I found it convenient (aka, my hands are on the keyboard, so might as well, type-in my wishlist for the feature/component/product). Here's an example of how my mind wonders when I start a design:
Hmmm...Ok, so I need to define an IPlugIn interface for my Smart Client shell, fair enough. It needs to have an ID and a Name to identify the plug-in. Wait...should I also add a type that defines extra information for each of the plug-ins (configuration, logging, ect.)? Yeah, that sounds like a good idea! I'll just write it down (code it) within the interface and I can deal with it later. Gee, I wonder what I might need next for this interface...
Crazy, huh? Well, after JP and James held my hand as I entered the world of TDD, I must say that I was way wrong. That's right, I was wrong.
With TDD, I can accomplish the same design with a nice solid intent (the test). I can use the test as my thought process to drive out the design exactly the same way as I was trying to do with my previous process. Now you might be asking, how was I wrong? I was wrong by not seeing (believing) that I can drive out the same type of design by thinking through it with client code (aka a test). This is kinda the same notion as the whole contract-first vs. code-first approach for designing services (oh yeah, can you guess what I use?).
On a personal note, thank you JP and James for taking the time (and patience) for stepping me through the different scenarios and thoughts that one must first come with terms to fully embrace the TDD approach. Also, if you're contemplating starting TDD, you should check out the TDD content that both JP and James have on their websites. They're both great coaches and are very passionate about what they do (I guess that's the reason why they're rockstars ;-) ).