Since I got my iPod I've subscribed to the DotNetRocks (DNR) podcast.  The first one I listened to was from 3/21 with Jean-Paul Boodhoo on TDD.  It was enlightening to say the least.  Someone who uses it daily, designs software with it, and can give real life experience on the topic was awesome! 

We don't use TDD where I work but I've used it on a few smaller projects and personal projects so I could see what the fuss was all about.  After listening to Jean-Paul I realized I really wasn't doing TDD all.  I would write some code and then right the unit test for the code.  According the Jean-Paul, TDD is where you write the unit test against your idea of what the code will do and then write the code to make the test pass.  Think about that.  You are writing a test for code that doesn't even exist.  So basically you have an idea of what you want your code to do, what results that should return from it, and that's what you use to write your tests.  That's a mind shift and something to get your head around.  Another thing to get your head around is that TDD is not a testing strategy but a design strategy.  I think I just got this listening to Jean-Paul's interview.  One thing I've felt as an advantage to TDD is the extra thought that has to go into your design and how the pieces will work together.  I don't know about you but more than once I've sat down to write some code and then coded myself into a corner and had to do some heavy refactoring to clean it up.  Maybe, don't know for sure, but maybe if I was doing it TDD style I would've seen something like that coming sooner?  Or maybe it is just me.  :-)

What prompted me to even blog about this was Jeffery Palermo's post last Friday but more importantly the comments.  In the comments are somewhat of a debate on what is good/bad/ugly with TDD.  The comment that stuck out the most was Brian Sherwin's:

 Brian Sherwin said:
 The biggest problem here is that there are really three groups that don't get along real well with each other.
 First, there is the group that says "ALL code has to have a test FIRST" (hardcore TDD).
 The second group says, "We don't have time to write all of these tests before we write code--too much time is built running the tests just to see red when I know it's going to fail.  That's just STUPID." (TDD is for idiots).
 The third group says, "Wow, unit testing gives me confidence to refactor.  I should have unit tests to cover all my code.  I should at least be thinking of how to write the test as I'm doing the development, and ideally, I write that test soon after I wrote the code.  TDD is too much, not TDD is too little."  (Both sides can work.)
 I'll be honest--I don't TDD *ALL* of my code.  I do however TDD any refactorings.  Recently I was rewriting a module of a huge application I am working with, and the approach was--write a test that exercised the method I was replacing/rewrite code/verify new method returns the exact same results.
     Assert.AreEqual(Obj1.TestMethod, Obj2.TestMethod)

I totally agree with him.  I typically fall into group #2 but I'm think I'm slowly moving to group #3.  Group #1 is too absolute for me and to me there is only one thing that is absolute.

Anywho, there are also two DNRTv episodes (#1 & #2) where Jean-Paul develops an app from scratch using TDD.  I've got them downloaded and ready to go.  I'm sure they are great as Jean-Paul is on the teaching side of TDD and not the "if you don't use TDD you stink" side. 

Giddy Up!