Agile Zone is brought to you in partnership with:

Gil Zilberfeld has been in software since childhood, starting out with Logo turtles. With more than 15 years of developing commercial software, he has vast experience in software methodology and practices. Gil is the product manager at Typemock, working as part of an agile team in an agile company, creating tools for agile developers. He promotes unit testing and other design practices, down–to–earth agile methods, and some incredibly cool tools. Gil speaks locally in Israel and internationally about unit testing, TDD, and agile practices and communication. And in his spare time he kills dragons, for fun. Gil blogs at http://www.gilzilberfeld.com on different agile topics, including processes, communication and unit testing. Gil is a DZone MVB and is not an employee of DZone and has posted 52 posts at DZone. You can read more from them at their website. View Full User Profile

Test-Driven Discipline

05.07.2014
| 7260 views |
  • submit to reddit

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:

    1. There’s a lot of internal logic involved and we want to make sure it’s correct
    2. We’re not sure what the right design is
    3. 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.

Published at DZone with permission of Gil Zilberfeld, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)