Okay, well more like:
Kent Beck Suggests Skipping Testing for Very Short Term Projects
As discussed by Mark Levison here.
It’s like many things in software — a judgement call.
I agree wholeheartedly with Kent.
If you are in a highly exploratory phase… just trying out a few ideas to see what might work before committing to an approach, why bother with TDD?
Now, if you are lousy at design and doing exploratory work, and you prefer TDD — then use it! Use your best judgement to make that decision based on your current situation.
Caveat Emptor: I am not an expert in TDD, nor have I done it more than a handful of times.
Aside #1
I have always wondered this… as it seems to be a built-in assumption on the part of TDD advocacy. Does TDD necessarily lead to good design? Philosophically, I don’t see how it can be an immutable assertion.
Aside #2
In 2001, when we were in Snowbird for the Agile Manifesto gathering, I remember doing an example of TDD with Bob Martin. After we did a simple example in Java, I turned to another technique to “write” the tests and code. In Together, we had built a feature that allowed sequence diagrams to generate code. Writing tests as a sequence diagram was fun… create test classes, invoke application objects, create the classes for those objects, create methods, add code, execute the tests. Rinse and repeat.
Aside #3
Typically I design by starting with objects… I don’t need tests to tell me the core aspects of the system — but that is my personal choice. Features typically indicate core methods that are needed. When we need to flesh out nitty-gritty logic and what not, then I will turn to sequence diagrams — which could be done with TDD.
Aside #4
I can see where TDD would really help to benefit in ensuring folks stop coding just as soon as the test passes — assuming of course that the test is at the proper “correctness” level.
Summary
For me, I chose to be pragmatic, NOT dogmatic. I chose to use my brain to do what makes the most sense in every circumstance, not a blind allegiance to a process for process’ sake. If barging forward and doing “design and coding” works best for you and your team to flesh out ideas, go for it. Just be sure to go back in and “do the right things” once you commit to an approach that is going to stay in the code base.