Not Caving In on TDD

TDD causes different people react to it in a completely different way. Some just jump on it like on a glass of a cold sparkling drink in the heat of a summer day. Some run away from it like it’s a wild dog ready to take a bite. Some feel that there might be a value for them in it, but don’t really want to move away from the comfort zone. And the last group of people always have an interesting way making an attempt to justify why having no TDD is good.

A classical example would be the current project I work on – integrating .NET sub-system with C++ components/subsystem. I stick to TDD because I know the value is enormous, but not instantaneous, it comes with time. During integration with C++ subsystem, there was some weird behaviour with no clarity where would it break (managed or unmanaged code). Sure thing my steps where to validate that all tests cases present. And sure they did. Within seconds I could not only confirm that I am dealing with all various edge-cases, but also run the “executable specifications” to verify code adheres to expected behaviour / design. And guess what, the bug was identified on… the side where developer was so convinced that “previous experience would compensate for lack of tests” that there’s no point of even bothering with TDD. Ironic.

But what’s the moral of the story?

If you on your path to start TDD, or trying to show others the benefits – don’t cave in, be patient and keep doing what you do. It is unavoidable, and eventually the simple truth will come out. TDD works just like medicine – once it’s in the blood stream, it will sure kick in.


  • I just saw a tweat from @UncleBobMartin

    "If programmers were meant to test everything, God would have given them brains."

    Perhaps a little non-diplomatic.

    Before introducing TDD (a method of programming) into the equation you would be wise to get agreement on the desired outcome: i.e. clean, supportable code with minimal defects.

    If you can't agree on the outcome, you won't agree on the method.

    Once you agree on the desired outcome then the rest of the conversation is around the best method to get there. If you truly believe TDD is the best method to get there, then prove it over time. Most people who truly believe in the outcome will come around over time to better ideas.

    If both don't agree to the desired outcome you have bigger problems than TDD discussions.

    (I think I have the seed for my next post).

  • I love how people get God involved :)
    Outcome is simple - quality software, a rear bird to find in the wild.

  • This is a popular approach to describing the benefits of TDD. It's basically, "We don't understand logically why TDD works, but if you try it, you'll find out for yourself."

    This is unscientific.

    If you can't describe how TDD works - if you can't take its axioms and logically argue to supporting proposition - if you can only "prove" its value by resorting to empirical anecdote - then TDD is no better than religion.

    It speaks volumes about TDD that its priesthood proclaim it from their high churches yet cannot logically deduce any of its properties.

  • @Shmoo,

    There's no religion in TDD. You want "schientific" proof? Here's some of it:
    - Significantly lower defects rate (proven)
    - Better design (proven)
    - Mechanism to make changes throughout time as projects progress (proven)
    - Executable specification - living-breathing documentation (proven)

    On a personal level, I have actually lived it for a few years, so this is not "theory" preached. I have also spend quiet a few good years working w/o TDD, and seeing the results as well. So please, next time when you leave a comment, be better prepared.

Comments have been disabled for this content.