I've had a couple of experiences recently which make me think I've fallen off the one true path of test-driven development.
I have developed a tendency to step out of TDD style when I'm trying to get an idea as quickly out my head and into code as possible. When I do this I work in a tight loop of thinkcodelook where the last part is examining the output to see if it has what I was after. This is often exploratory experimental work where I don't actually know what the output will be. Test-driven development can only hamper this initial foray.
After I've done a little of this I switch back to solidify and shore-up what I've done by writing tests to confirm what I think I've done is what I've actually done. Now, it's not unusual for this stage to find some bugs. But then I ask myself: if I'd done this a step at a time, with each step carefully checked, would I have reached my unspecified goal? Does it actually matter that I introduced a bug if that bug serendipitously led me to an interesting result?
Incidentally, it's funny that I often only write an equals and hashCode implementation in the second stage. The code I'm working on often consists of maps to this and that, where the value is often never used as a key or in equality comparisons. The production code simply doesn't need it. Yet, I find myself writing equals and hashCode first when I do TDD as the style often requires comparison of expected and actual values.
Similarly, I beef up the API of a class when I'm using TDD because I want to test all of it's behaviours. Yet, sometimes those methods are only ever used by Junit tests. Hmm, could Eclipse me modified or configured to show a warning if a method is never used by production code?
When it comes down to it, TDD is really just another programming style and not dogma. It is simply not always the best thing to do. Join me next week, where I question the value of continuous pairing. Heretic!