My First TDD Experience

My First TDD Experience

** Want to try TDD, but don’t know how to start? Watch our webinar “Intro to TDD“ **

I sometimes tell the following story to illustrate what unit testing and TDD are really all about: people.

It was roughly a decade ago. I just finished reading Kent Beck’s excellent book “Test Driven Development By Example”. I was on an agile ride those days, reading about it, searching for more information. Everything I read looked promising, but this one was different.

It had code in it.

I was a project manager, yet still developed parts of the code. While the process stuff looked impossible to do in my environment (I started with Feature Driven Development, mind you), this TDD thing I could do. Because, after all, it’s writing code.

So I decided to try it. On myself.

I mean, what’s the point of starting a new thing with my team if I don’t understand it first? I had to have the answers when asked, right?

(people stuff- that includes hubris kids).

The Experiment

Anyway, I was working on a communication component at the time, and I decided to write it test-first. I downloaded a test framework and started writing tests. I still remember the first test: it was sending a message, and checking that I received it. It was working like a charm.

At first.

The simple test ran a few times, and began failing intermittently.  I noticed that the asynchronic communication had something to do with it.

A-ha! Time for an abstraction, just like in the book!

So I wrote an abstraction. And continued to write more tests. And abstractions.

And two days later I gave up.

There was so much coding around the real code, I felt that I could never convince my team to do that. If it doesn’t work for me how will they ever succeed?

(See the pattern?)

And I said the sentence that I’ve heard so many times since: TDD may look good in books and theory, but not in the real world.

The Result

It wasn’t about how-tos (although there were not many then).

It wasn’t about techniques (although there are many, I know now).

It was just too hard.

And people (even me) don’t like hard.

Want to know a secret? Even today with all the tools around (including Typemock’s magical tools) and books, and blogs – It’s still hard.

They don’t call TDD a discipline for nothing. That’s a people thing, discipline.

And software, testing, TDD and everything – it’s all about people.


The good news – I’ve recovered since. I encourage people to try it too, because it’s possible.

And it’s worth it.


Want to try TDD, but don’t know how to start? Watch Gil’s webinarIntro to TDD


  1. Thiago October 3, 2013 at 10:27 pm

    That picture is fantastic. I just started learning how to do c++ unit testing a little while ago, so this is going to be useful for me.

  2. Adhiraj April 2, 2015 at 8:26 pm

    It does not seem unreasonable to suggest that in science TDD is the best practices ever to make the proposition grand in all the way. it is strong likelihood that if anything needs to expand or show in the practical world then TDD is the perfect example in all the way to prove as well as make the guidance to name new scientific names to all. The essay writing service also can help.Thanks for sharing the great story to all.

  3. Patricia Moncrief July 22, 2015 at 9:13 am

    The test driven development is one of the great technique and your blog is nicely described about it. So thank you for this kind of information and you can use this best essay writing service for future writing support.

Leave a reply

Required fields are marked (*)