As the ”Is TDD Dead or Alive” continues, it is interesting to see the different kind of discussions. Here’s an example:
The new default answer to TDD critics: How Would You Know?
— Darren Cauthon (@darrencauthon) May 5, 2014
Not much of a two way conversation there.
In contrast to the tweet above, people who were disappointed by TDD, actually have used it. Maybe to the letter, or maybe not. The fact is, they think TDD let them down.
And I get why
Here’s a recent story.
Recently, working on an 6 year old code base, we wanted to add some new functionality. We’ve decided to use TDD for the new components, and then embed them into the codebase. This would be covered by new integration-test, we’ve written upfront.
So far, so good. By-the-book test first.
We wanted to use TDD, since:
- There’s a lot of internal logic involved and we want to make sure it’s correct
- We’re not sure what the right design is
- Developing the new functionality away from the current implementation gives us better control, and quicker feedback.
My partner was new to TDD, and we’ve paired on this for a couple of days, moving from class to class, adding tests and seeing them pass.
In just a few days, I’ve encountered two kinds of struggles.
The first one was between the two of us. Me pushing for incremental steps, test-code-refactor, don’t jump ahead method. In other words, restraining my partner.
I could see how it tormented him. There were moments of appreciation to the evolving design, but more moments of “I’ll play along, but not for the fun of it”. Indeed, at the end of the second day we split, and re-joined a day later. He added some code to the existing codebase, without tests and not part of the new design.
The second one was internal – as work continued, we’ve added more and more tests, changed the design a couple of times, renamed and extracted. All the good stuff that comes with TDD. Yet a little voice kept talking inside my head. It said: “All this work could be done in a few hours, you’re working too much for this task”.
That’s the result of two days of work. How much struggle do you think months of projects involve? Can everyone weather the storms?
TDD is a discipline
I usually explain TDD as a methodology, then later explain it’s really a discipline, in both senses of the word. Using TDD requires discipline and confidence, not to give in to the dark side. Which may not always be so dark. Or may not seem like it.
The people who swear by TDD have grown this discipline, as well as many skills to make it work and avoid so many pot-holes.
Many have conquered that little voice in their head. But I bet it’s still there.
The people who were disappointed were not able to do this. It’s easy to say “they don’t understand it”, or “they didn’t stick around to see the value”, or “how would you know”.
I think the disappointment comes from an unfulfilled promise: We describe TDD as simple, just following a few steps.
Nobody talks about the constant struggle between people with different skills, the pressure to complete tasks quickly, and the totality of it all: No compromises, or you’re doing it wrong.
Here’s the whole truth: Stick with it, and you’ll get rewards.
But know this: TDD is hard work.
I hope you won’t get disappointed.
| Reference: | Test Driven Discipline from our JCG partner Gil Zilberfeld at the Geek Out of Water blog. |
I kinda get around the annoyance of moving so slowly by building a module up first, then testing it immediately. By actually writing the code for the module first, I tend to be able to work through how I actually want it built and then I only have to recode things inside the actual module if I notice better ways of doing things rather than having to change all the tests too. Also, the quick shifting back and forth constantly with tiny incremental changes is avoided, saving time. As long as a module is well-tested before being released into the… Read more »