TDD – Totally Destructive Dogma - Karoly Nyisztor's website

“Start with the tests.”

Cool. Here you go:

testSomethingIMadeUp()

This is our first test. We just started the project, and there’s no design document yet. But we have to start somewhere, and we can tell the customer we’re doing TDD. Wow!

Later, Mr. Architect will come up with great ideas.

Oh, wait, we’re Agile! No architect, no design docs, just a whiteboard. Let’s clean it up. It still has that funny Dilbert cartoon David drew a few months back, right the day before he was let go…

Now we can start brainstorming. Ok, let’s think of our software. It needs some components, then those smaller gizmos inside the components…

How do we call them? Oh, right, classes! I recall we used rectangles to draw them. So this big rectangle has many small rectangles inside, and we connect them using these wires. Done!

This is our design! And here, we add some public methods. Starting with this ‘Manager’ class. Why ‘Manager’? It’s an insider joke; you wouldn’t get it.

So, ‘Manager’ has two methods for now.

fire()

and

forget()

Good. It’s noon already, so let’s get our hands dirty and start implementing something.

Oh, wait! We’re doing this TDD thing! Tests first!

testFire() {
    return false
}

testForget() {
    return false
}

We don’t have the actual implementation yet, so our tests should fail.

And now, we can start implementing the actual methods. Once the methods are ready, we adjust the tests:

testFire() {
    // if fire() behaves as expected, return true; otherwise the test shoud fail
}

testForget() {
        // if forget() behaves as expected, return true; otherwise the test shoud fail
}

Now comes the next class. We create our tests. Implement the methods. Update the tests. Rinse and repeat.

Soon, things are beginning to take shape, and we’re proudly doing our TDD thing.

But then, someone comes up with a revolutionary idea: let’s revamp our design. The new hire knows a better framework, which is faster and uses less memory.

Awesome! But unfortunately, the new framework is not compatible with the old one. No problem! We’ll do some slight refactoring here and there.

But wait! Now the old unit tests also need to be updated. We have one fewer component, and twelve classes have been revamped. The public API has completely changed.

Ah, TDD! Let’s redo the tests first. Something’s broken. Nothing works, and the review is in two days! For f%$@s sake!

You know what! I know how to save the day: let’s ditch the tests! Yes, I said it. As the only senior developer, I take responsibility and delete all those tests. We’re not doing this.

Bye, TDD!

And we managed to revamp the software and get it working just a few hours before the demo. With the extra maintenance for the tests, we wouldn’t have made it.

The customers enjoyed the demo and asked all kinds of questions. Guess what they didn’t ask even once? Yes, you guessed it right: none of them asked whether we used TDD.

Once the design and our public interfaces were consolidated, we added the missing unit tests. Quality is crucial, and testing is a key part of it.

But TDD? We ditched it. And no one asked about it.

Well, except for the boss’s boss’s boss once. And we gave him a reassuring “Yes” and showed him the beautiful green checks on our repo’s CI page.

He nodded in satisfaction:

See, I told you you’ll LOVE TDD!