Photo of Daniel Irvine

Beyond TDD: breaking the rules

Rules are made to be broken, right? TDD is a strict set of rules that define a process for building software. But experienced practitioners have moved beyond the rules and work towards something else entirely.

Daniel Irvine · Jan 23, 2020 · career tdd

Ron Jeffries wrote a tweet thread in which he discussed the notion of what he calls pure TDD (PTDD), and is sometimes called strict TDD. He talked about how he doesn’t like to subscribe to this purest approach.

But rule-breaking is an acceptable part of any skillful process.

The Dreyfus model of skill acquisition talks about skilled experts being intuitively aware of rules and can make decisions without conscious thought. That means they know not only how to apply rules but also when to ignore rules.

Then there’s the four stages of competence model which goes from unconscious incompetence—you don’t know what you don’t know—through conscious incompetence and conscious competence and finally to unconscious competence which, again, is saying that experts are intuitively aware of what they’re doing without having to think about it.

What does it mean to be intuitive?

In some sense, the word intuitive means you no longer need rules. Instead you understand the core values behind the rules, and work towards those values, not the rules.

Because you know the values behind the rules, you can understand the trade-offs involved. You can begin to see when the rules might not apply. You can begin to answer the question “when should I use TDD, and when should I not?”

Contrast this with TDD aficionados. Many of them will want to use TDD all the time, because TDD is just so amazingly great when you get the hang of it. (I’m not being sarcastic here; it really is great.) We have a phrase for this attitude: “If all you have is a hammer, everything looks like a nail.”

When is it okay to NOT use TDD? When can I cheat?

Assuming then that you agree with me that it’s okay to move beyond the rules, then on what occasions should we do so?

Here are some I can think of.

But the rules are still VERY important.

A common belief in education is that experts make bad teachers. This follows naturally from the Dreyfus model if you think that being intuitive means losing sight of the rules.

This doesn’t mean that all experts are bad teachers. Actually they can make great teachers. They just have to put in extra effort to be great, otherwise they might very well suck.

If you’re involved with working with novices, which is typical for the industry today with mixed skill-level teams, then you must be able to switch back into “pure TDD” mode.

When MUST I use TDD?

So we can now start to see occasions when TDD is ultra-important and should not be skipped. Here are the two that come to my mind: