Claudio Lassala's Blog

That’s another common question: Is TDD something you do sometimes or all the time?

The short answer is neither. Or, “it depends”.

But let’s explore the long answer…

When I started learning TDD, yes, I’d do it all the time.

“But have you always worked on projects where you could do TDD all the time?!”

Most certainly I have NOT!

There are times when I can’t do TDD on a project.
That doesn’t prevent me from still doing it on the side.
I learn and practice it on my own time.

TDD became something I do most of the time, but never all the time.

So when do I NOT do TDD?

There are situations when I specifically choose not to do TDD. Here are some that come to mind…

Exploring a library or framework

When trying to learn what a library or framework can do for me, and how I’m supposed to use it.

Once I identify ways I’ll use it, I often refactor those tests into Given-When-Then, documenting my understanding and assumptions, so I can later remember what parts of it I’m using.

That approach also provides a safety net when consuming updates to those packages (identifying breaking changes and such).

Exploring approaches

Sometimes I need to implement features that currently lack clarity, so I want to gather feedback from stakeholders as soon as possible. I may try a few different approaches and won’t do TDD.

I will, however, use BDD (Behavior Driven Development) to describe, to the best of my ability, the feature we’re building.

Solving small problems

If a problem is too small and yields very little value, I may skip TDD.

Pitfalls of TDD

Remember Design Patternitis? That’s something most developers face when we learn Design Patterns; we start trying to apply them everywhere! As mentioned earlier, TDD is not something to be done always, everywhere, every time.

Another situation I see often is “copy-and-paste inheritance”; tests are initially written carefully following TDD, but then every new test comes from copy-and-paste, without any effort going into refactoring the test code. This is a pitfall that happens in most automated tests, and tests written following TDD can also suffer from it.

But BDD…

I try to do BDD most of the time, even if it means writing the stories and scenarios on a napkin.

Many times I don’t even know how I’ll actually implement the specs/tests, but I still write those English sentences before trying to write any code. No GWT, No Code!