chevron-thin-right chevron-thin-left brand cancel-circle search youtube-icon google-plus-icon linkedin-icon facebook-icon twitter-icon toolbox download check linkedin phone twitter-old google-plus facebook profile-male chat calendar profile-male

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.

PS

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