I was in an interview a couple of weeks ago for a digital agency who needed a developer to come in for a relatively short term project with fairly tight deadlines. During the conversation, I broached the subject of TDD and whether they would be open to me working in that way. The response was one I've heard many times before: "if it slows us down then no, deadlines are too tight". I didn't press the point but it was interesting to note that the initial reaction was negative and some measure of persuasion would need to be employed to get management buy in. I've worked on projects in the past that took that approach, and they fairly quickly degenerated into maintenance nightmares. It doesn't take very long for a software project to become complex and inter-related to the point that it becomes unclear whether changes to the core parts of the code base will have unintended consequences for other, seemingly unrelated, parts. The benefits of a solid framework of unit tests only really become apparent when the project reaches its final critical stages, when time is short and those hard to track down bugs rear their heads. Fixing one causes others to appear and the pressure mounts.
It's Not Unit Testing, It's Assumption Challenging
In an effort to find a way to sell the concept to management, I've started thinking of unit testing more as assumption challenging. As a developer, when you make a change to a part of the system, you assume that change won't introduce bugs or have unintended consequences (at least, I hope you do!) Having a framework of unit tests challenges that assumption. If your assumption is wrong, a test should go red somewhere. Even if it doesn't and you introduce a bug, you can write a test to ensure that you don't re-introduce that bug at a later date.
I've not had a chance to use this line of thinking with a client thus far. In the interview room is probably not the best place for a potential battle of wills, but I'm sure I'll get the opportunity in the near future given the proportion of companies who haven't embraced TDD as a development standard yet. I'd be interested to hear any success (or not) stories people have had trying to convince their organization or project team to embrace TDD.
View the original article.
