I’m a big fan of Test Driven Development, and even more of a fan of Behaviour Driven Development. So it makes me sad to see really great developers adopt these techniques a bit too dogmatically.
Most developers operate in two modes when they’re writing code. Test driven development helps amazingly with only one of them. Use it for the alternative and you’ll quickly become frustrated, hate TDD and never use it again.
What are these modes? Experimentation and, what I call Focused mode.
Experimentation mode’s main objective is learning. It might involve poking at a library, tool, language or framework to understand how it works, how to interact with it, and perhaps understand some of its limitations. You might learn how to configure it, how to deploy it, and even how to test it. If you write code, it usually is throw away code because you don’t apply the same level of code quality because it stops you learning about things quickly. When people apply TDD during this mode, the first normal hurdle is they don’t know where they should be test driving it because they haven’t learned where the cost-benefits payback lies. They spend a long time writing their test only to find out the thing they’re doing won’t work in that way and then sulk over the time spent writing the test.
Focused mode’s main objective is producing something that will be put into production, used by people and extended upon. Here you want to write just enough code to provide the correct functionality. This is the most ideal time to apply TDD. You care about the quality of the code you produce here.
Recognise what mode you’re operating in, and understand where to apply (and where not to apply) TDD to get maximum benefits. In short, avoid TDD during experimentation and use it when you’re focused.
