David Tchepak on TDD
David Tchepak wrote a thoughtful post on TDD. I share what he says. I find useful this little summary:
The process of writing the test gives us all sorts of feedback.
- The setup is too long or complicated? We’ve probably got too many collaborators (or are violating the Law of Demeter for them) and can try encapsulating them behind a new abstraction.
- Too many scenarios or test fixtures on the same SUT? Our SUT probably has too many responsibilities.
- Too hard to isolate the behaviour we’re trying to test, or can’t find how to write an assert for the behaviour? Maybe the current API or abstraction is wrong, and needs to be broken down differently?
[…] Writing the test first gives us ample opportunity to respond to this feedback, to sketch out our design, before committing to it. There is no cheaper time to change your code than before it is written.
The article is full of little gems like this note:
If you can’t get TDD to help you with a problem, make a note of it before trying something else, and come back to it later. It is important to see if it was just a problem TDD was ill-suited for, or whether a gap in your knowledge has been exposed. You’ll never know the difference if you give up too easily on TDD. Pursuing these leads is what led me to discover mocking, IoC containers, conventions, BDD etc. And I’m far from finished finding gaps in my knowledge. ;)
I like this tone. He does admit that TDD will not always for us, yet he advises not to accept that as a fact. Every obstacle in our work should be a reason to sit down and think what we could have done differently. Just as a team should not accept bugs as an inevitable fact of life, but should treat each one as an indication that they must do something to improve their process, the same should apply to when we are “stuck” not knowing how to proceed, or when we don’t like how our code turned out to be. Think about it; what part in our process could have been improved so that this does not happen again? (And if this leads me to think “my process? what process??”, great! I’m on the right path to improve :-)