July 26, 2007

TDD: Are you a purist?

by Brian Donahue

I ran across this postBroken Link: http://chriswoodill.blogspot.com/2007/07/test-driven-development-when-writing.html by Chris Woodill about green field TDD.  He suggests that a purist TDD approach (write a test that fails, write minimal code to make it pass, and then refactor) is not really practical in most cases.  He believes that writing a first "spike" of working code that achieves a basic use case is more fruitful, and feels more productive.  

I know how he feels - and I always feel like I must not be grokking the TDD way when I "cheat" like that.  I think part of it might be that the tests I try to write before code are not good enough tests - maybe they are either too broad or too granular.  Or maybe I am not thinking enough through the design first.  Another complication that often comes up is that I am testing things that interact with concrete objects like HttpContext, HttpApplication, or others.  Some are easy to mock out or abstract, but some are not (more on that in another post).  But, as I think is the case with many programmers, coding *is* often the best way to think through the design.  So, many times I do end up getting some basic code working, then going back and kind of re-doing it TDD, or at least adding tests, and continuing in a more TDD fashion. 

So, I'd love to hear from some of the hard core TDD experts out there (two of my faves being Jean-Paul BoodhooBroken Link: http://www.jpboodhoo.com/ and Jeremy MillerBroken Link: http://codebetter.com/blogs/jeremy.miller/default.aspx) about how "pure" they are in their TDD approach, and what skills/experiences/lessons are required to get past some of the above issues that keep us TDD wannabes from being more "pure!"

If you're a TDD expert OR wannabe - what do you think?