The effects of TDD still involve many unknowns. Indeed, the evidence is not undisputedly consistent regarding TDD’s effects on any of the measures we applied: internal and external quality, productivity, or test quality. Much of the inconsistency likely can be attributed to internal factors not fully described in the TDD trials. Thus, TDD is bound to remain a controversial topic of debate and research.
For practitioners looking for some actionable advice, our expert panel recommends taking the TDD pill, carefully monitoring its interactions and side effects, and increasing or decreasing the dosage accordingly. So we end with some specific prescriptions from individual members of our team, after reviewing the data:
We’ve been able to compile the evidence, but each reader has to make up his or her own mind. First, decide which qualities matter most to you. For example, do you care more about productivity or external quality? Can you justify spending more effort to create higher-quality tests? The evidence in this chapter is useful only for making decisions based on each reader’s specific goals.
I have taken the TDD pill and become hooked. My personal experience has been that TDD improves productivity, although evidence from our study is lacking in this regard. Perhaps mine was simply a perception. Based on these results, especially based on the evidence regarding its conservatively positive impact on external quality, if I weren’t already using TDD, I’d start having my team take it in small doses and see whether they find a long-term productivity improvement of their own. If there are no adverse reactions, I’d increase the dosage gradually and keep observing.
Although TDD is promising, its adoption can be impeded by uncertainties about its effectiveness and by high up-front adoption cost. Still, its ingredients seem to encourage good programming and development habits to flourish, yielding better-quality programmers and tests in the long run.
TDD seems promising, but let’s face it, it tastes bad when you first start. A lot of people like the old stuff better. After all, it’s hard to feel productive when you spend a large amount of your time writing test cases that fail. On the other hand, I’ve never written cleaner code in my life, and it feels great to make a change to that old code, hit the “Run Tests” button, and be confident that I didn’t break anything.
The evidence packed into this chapter shows that TDD might be a cure for you, yet you should not try to use it as a panacea. Your TDD adventure is likely to vary with certain factors, including your experience and the context you are working in. As a practitioner, developing an insight about when to expect improvements from TDD would be a valuable asset.