Driving with your hands at 10 and 2

August 20, 2022
Maybe strict TDD isn't necessary for experts, but it's still useful to learn.

Yesterday I looked at a study about Test-Driven Development that concluded that it’s not TDD, per se, that is valuable to code quality, but rather, it’s the granularity of our coding cycles.

I’ve heard many people take this finding to mean that TDD is superfluous. “As long as you work in short cycles, you don’t need TDD.”

Okay. That’s basically what we just agreed to. However… Fucci continues:

This granularity is a biproduct of TDD.

Oh. So maybe TDD is important… but as a means to an end, rather than its own end?

The study mentioned in the video surveyed expert TDD practitioners. Look at experts in any field, and they often bend or break the so-called “rules”. In fact, one charactaristic often attributed to experts, is that they know when to disregard rigidity.

So I see this a bit like the advice I learned in my drivers’ education course to put my hands at 10 and 2 on the steering wheel.

If we do a survey of expert drivers, how many drive this way all the time? Probably close to zero.

Does that mean that the 10 & 2 advice is bad advice for a beginner? Of course not. We often tell beginners to use a technique that’s appropriate to their skill level, which we expect they will partially, or even completely abandon later.

There are still times when I revert to the 10 and 2 position while driving. Usually when I need heavy concentration. Perhaps during a heavy rainstorm, or while navigating through a busy city at dusk.

So where does this leave me with TDD?

I do not strictly adhere to the TDD red/green/refactor mantra. This is (somewhat embarassingly) obvious every time I do a live TDD demonstration, and catch myself jumping around.

I do know how to strictly adhere. And sometimes I do follow that pattern strictly. I used to be a lot more strict in the past.

I do think it’s important to learn and know the steps, and to become proficient at them. Only after proficiency, can true expertise (that leads to relaxing the rules) be achieved.

In other words, I see TDD as a necessary* step along the way to writing code in short loops.

*If someone can demonstrate some other way to achieve consistently short test/code or code/test loops, I’m fully prepared to alter my opinion. I’ve just never met anyone who got to that stage by any way other than TDD. But if you know of such a person, or a technique, I’d honestly love to hear about it!

Share this

Related Content

It's the granularity that matters

It's not the red/green/refactor cycle. The important thing is working in short test/code or code/test cycles.

Test-Driven CI pipelines

Test-Driven doesn't only apply to normal code.

TDD only makes sense if you already know the outcome... or does it?

If you don't know what your code should be doing, you have no business writing any code anyway!