he Having read The Clean Coder recently, a section that really struck a chord with me discussed the application of TDD in projects as a day-to-day practice. The gist of the chapter was that when the pressure is on, and deadlines are creeping up – say either at the end of a big-bang delivery or at the end of a sprint – TDD is one of the first things to get dropped off by the developer in an attempt to get more “done”.
Of course, all that’s really happened is that the developer has changed their definition of “done” from something that’s unit-tested in a repeatable way and will automatically alert you if it gets broken to something that you simply think works at the moment of check in. It suggests that the developer is only doing TDD because it’s an expensive “safety net” that’s there as a precaution rather than as a first-class citizen of your codebase.
When I see this, I generally say one of two things: –
If you need to dump unit testing now, surely that’s suggesting that it’s quicker to get things done without unit testing. If that’s the case, why bother with unit testing at all?
If it’s quicker to code without unit tests, wouldn’t it also be quicker to code without bothering to compile and run your application every few minutes when coding? Why not simply type away for a couple of hours and then check it in to source control (surely you won’t have made any mistakes)? (Believe it or not, I actually read about someone that once went several days without compiling his code and thought he was “done”).
The long and the short of it is – if you believe in unit testing and TDD, then the most important time to use it is when the going gets tough – when the pressure is really on. If you drop it when it’s “convenient” to do so, then in my humble opinion, you’re not a true believer in it.