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

My 5 best reads of 2021

As I read a lot, I thought I'd recap my best reads of 2021. Perhaps you'll find something for your 2022 reading list.

Adventures In DevOps 096: What Certificates Should I Get?

The Adventures in DevOps crew discuss the various certificates that exist and which ones you may or may not want to consider getting.

Learning tacit knowledge is hard

You might hire a golf coach who watches you to discover your "bad habits", then convert them into explicit knowledge so they can be corrected. It's no different in business.