Test Driven Discipline

As the ”Is TDD Dead or Alive” continues, it is interesting to see the different kind of discussions. Here’s an example:

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.demotivationalDISCIPLINE_zps1e3eaf66

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.

Reference: Test Driven Discipline from our JCG partner Gil Zilberfeld at the Geek Out of Water blog.
Related Whitepaper:

Software Architecture

This guide will introduce you to the world of Software Architecture!

This 162 page guide will cover topics within the field of software architecture including: software architecture as a solution balancing the concerns of different stakeholders, quality assurance, methods to describe and evaluate architectures, the influence of architecture on reuse, and the life cycle of a system and its architecture. This guide concludes with a comparison between the professions of software architect and software engineer.

Get it Now!  

One Response to "Test Driven Discipline"

  1. 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 wild or given to other developers, I think you’ve done what is right.

Leave a Reply


two + 2 =



Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use | Privacy Policy
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.

Sign up for our Newsletter

20,709 insiders are already enjoying weekly updates and complimentary whitepapers! Join them now to gain exclusive access to the latest news in the Java world, as well as insights about Android, Scala, Groovy and other related technologies.

As an extra bonus, by joining you will get our brand new e-books, published by Java Code Geeks and their JCG partners for your reading pleasure! Enter your info and stay on top of things,

  • Fresh trends
  • Cases and examples
  • Research and insights
  • Two complimentary e-books