I’d written an article to my mailing list decrying the attitude of “TDD isn’t about testing, you idiot!” and a reader asked me a few things to clarify my position. In the process, they pointed me to an article that they considered a reasonable articulation of the issues revolving the importance of writing tests first, then asked me what I think about it.
A Response To “TDD Is About Design, Not Testing”
I don’t love “But if you’re doing TDD so that you’ll gain better test coverage, you have not only misunderstood TDD, you’ve misunderstood testing as well.” I especially don’t love “misunderstood”. I might say “missed the point” or “using a hammer to kill a fly”. If you want to increase test coverage, then you don’t need TDD, and moreover, TDD doesn’t necessarily lead you there, even though it probably leads you to an adjoining and similarly-nice neighborhood.
That said, I understand that one might write plainly and provocatively in order to seize eyeballs. We have to feed our families.
The rest of the article describes what differentiates TDD from unit testing, which I do routinely in my training courses. However, I don’t love “…we quickly see how TDD dissolves into nothing but an orientation towards unit tests”, since I infer from it that the author sees TDD as better than unit testing. This reeks of “Best Practices” thinking, which I prefer to avoid. I would prefer to say that TDD goes farther than unit testing, providing other benefits, while (mostly) not losing the benefits of unit testing. I would also say that I sometimes pause while test-driving something to do some microtesting (almost the same as unit testing) when I think I need it. While TDD involves a larger idea than unit testing, that doesn’t mean that TDD is a greater idea than unit testing. Each has its purpose.
Now, I understand the point: don’t do unit testing and call it “TDD”, because that’s confusing, wrong, whatever. I say that, too. I take pains to say, “if you want to write the tests after the code, then please don’t call that ‘TDD’, because the name assumes test-first programming”. Even so, if you are willing to change your design after you find out how difficult it is to write the tests, then perhaps you are doing TDD, but painfully slowly! To optimize, don’t write the code before you write the tests. I prefer this approach to the topic than “that’s not TDD”. When you say “That’s not TDD!” the other party can too easily ask “Who cares?!” and be right to ask. I don’t care, either.
I would even edit Bob Martin’s line, “The act of writing a unit test is more an act of design than of verification.” by saying, “When writing a microtest, we don’t just specify the behavior we want, but also often make design decisions. Over time, the programmer might shift from focusing on the former to focusing on the latter to considering them both very carefully. Herein lies some of the great power of TDD.” I prefer to avoid “you’re doing it wrong” and instead inviting the reader to consider “there’s more stuff here when you’re ready”.
Kelly Sutton, “Design Pressure”. “Design Pressure is the little voice in the back of your head made manifest by a crappy test with too much setup.”