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!