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. ¯\_(ツ)_/¯