The problem with TDD
Sometimes it’s hard to write tests before code. It’s easy when you have:
- a clear understanding of the domain
- an understand what the client wants to achieve
- an understanding the API’s you’ll use to do the job
But it’s much harder to write good tests if you don’t.
One possible solution is something I’ve started referring to as Chris Roos Test Driven Development.
Given a problem or feature you’re unfamiliar with, a great first step is to prototype the solution. Pick the primary success criteria and hack at the system until you have it doing what you think it should. Don’t consider any edge cases and don’t write any tests, just make it do the simplest, dirtiest thing possible. Once you have a clear understanding of the code and the problem, REVERT! This is really important. Don’t be tempted to retrofit tests on top of your hack, that’ll result in bad testing and messy code. Take what you’ve learnt and start a fresh. This time write tests and consider edge cases. You’ll work much more quickly with an understanding of the system and you’re code, tests and overall solution will reap the benefit.
While working with Chris at Reevoo he often used this method which always resulted in clear, concise code and tests, which is why I’ve attributed it to him.
