Thread by @RonJeffries

So, TDD. TDD, variously called Test-Driven Development or Test-Driven Design[*], is a very small technique with interesting results.

* I believe that @KentBeck has said he wishes he’d called it the latter, but he called it the former. And I could be wrong about that belief.
1/12

Anyway, when we TDD, we proceed by thinking of some tiny thing our software doesn’t do; writing some test code to show that it doesn’t do it (red); writing just enough code to get the test to go green; refactoring the code to make it clean; repeating.

2/12

What’s “tiny”? For me, if a TDD cycle goes over about ten minutes, I’m probably in a rat hole and should revert and try something more tiny. I’d likely do better with five minutes. There are exceptions, certainly.

3/12

What seems to me to happen with this cycle is that the tiny change I pick doesn’t require a lot of work, because it’s tiny. When I get to the refactoring part of the cycle, I’ve done enough design thinking, and the code is showing signals pointing to a design improvement.

4/12

Usually, because the design improvement has just reared its head, stepping that way is also small: create a class, give it some dummy behavior.

Sometimes, the change may take longer. If so, I can commit the working green code, and refactor for a bit more time.

5/12

For me, that time still should be short. I might do a fairly large refactoring but even then, it works best when I do it in tiny steps, with a legitimate commit possible after each one. Sitting with code checked out and not working is just not a legitimate state for me.

6/12

Stepping up one level, looking at these cycles, a few things happen: more and more functionality arises; a better and better design arises; the system is always working; tests and coverage grow “linearly” with functionality.

7/12

In that light, what is TDD “about”? It creates lots of tests, but to me it’s not about testing. It creates incrementally more capability, but to me it’s not about adding capability. To me, it’s a way of focusing my mind “simultaneously” on building clean code that works.

8/12

Clean code that works. That’s what I’m supposed to be doing here in programmer land, and that’s what I get, more reliably, with less stress, faster than otherwise, longer stronger more continuously softer towels and brighter brights.

9/12

To me, TDD is a tiny software development ritual that makes me more effective at balancing all the demands put on me as a programmer. I get well-designed code, with tests included.

10/12

Since only well-designed code is worth having, in my view, and since TDD ensures that, for me, my code is well designed. I think it’s mostly a design technique. The code demonstrably works, so it’s a testing technique also, in a sort of backward way.

11/12

For me, TDD ensures good design. For me, that’s what it’s about.

12/12

Apparently I /am/ wrong about that. KB reports Development is just fine with him. Not sure where I got the faulty memory.