How I learned TDD (the hard way)

March 2, 2021

The first time I remember seeing TDD demonstrated was in 2009 at the PgWest conference in Seattle. The talk was demonstrating the pgTAP framework for testing Postgres stored procedures.

I thought it looked interesting, so I rushed home to try it out. I wrote a few tests. I did a little TDD. And I hated it.

The tests I ended up with were brittle. The code I ended up with was hard to use. And most important, it took about 10x longer to write code this way. I quickly abandoned the technique, assuming it must just be for certain people, or certain situations, but it wasn’t for me!

A few years later, I read Michael Feather’s book Working Effectively with Legacy Code, in which he says:

legacy code is simply code without tests.

The rest of the book describes how to get untested code under test. This is a surprisingly difficult challenge in some cases. But after reading that book, I began to gradually write more and more tests whenever I created code—but still writing my tests after my code.

Over time (years, probably), I became better at writing tests. And critically, I began to see ways to structure my code, so that testing would become easier.

Once I started thinking in this new way, the switch to full-fledged TDD was much more natural.

All in all, it took me about 5 years, maybe longer, to go from TDD ignorant, to a TDD “hater”, to a TDD lover and advocate. I hope it doesn’t take everyone quite so long. ¯\_(ツ)_/¯


Related Content

Better code review

How can we encourage less superficial code reviews?

How can I eliminate technical debt?

You can't eliminate technical debt. Nor should you want to. But where does that leaev us?

Types of technical debt

Where does technical debt come from? Three main sources.