Over the weekend I listened to the latest .NET Rocks episode with John Lam.  I'm very keen on seeing and hearing about where the IronRuby project is going, so I found the interview very informational.  Although I enjoyed the entire show, one particular exchange between Carl and John stood out.  About half way through, Carl asked John whether he thought developers who don't do test driven development (TDD) and unit testing should be working in dynamic languages.  John made the wonderful assertion that he doesn't believe programmers that are not writing "unit tests" should be writing code in any language, regardless of whether the language is dynamic or statically typed.   Following that statement, John went on to mention that whether or not the code is test driven isn't nearly as important as whether the code has unit tests since the "test driven" approach is "extreme" and "dogmatic".  While I agree that the key is unit tests, I don't agree that a test driven approach is extreme or dogmatic.  In my opinion its the most pragmatic approach to writing code that is well designed and well tested.  The fact is, writing unit tests after the fact sucks!  Especially if "after the fact" is days or weeks after the real code is written.

When I first got started with TDD I didn't really understand what it was all about.  Rather than figure out what this magical red-green-refactor thing was all about I decided I'd just write some unit tests once I had my code written.  After a couple projects using this approach I started to realize that I really hated writing unit tests after the fact.  It was because of this hatred that I got started with test driven development.

Rather than testing being a pain in the ass task that I had to do when I finished writing my "real" code, testing became an instrumental step within the process of writing the "real" code.  Since I was using tests to figure out what code needed to be written, it became a vehicle by which I could design the code I was writing, rather than an afterthought.  I'm sure there are people out there that write great tests after the fact, however, I'm not one of them.  For me writing tests first isn't something extreme or dogmatic, it simple the only way I can write high quality code with solid test coverage without going nuts.  For me, writing unit tests after the fact sucks.  For me, driving my code with tests is a joy. 

I wonder how writing tests first could be "extreme" and "dogmatic" for others, but for me its pragmatic?