How I learned TDD (the hard way)
March 2, 2021The first time I saw TDD demonstrated I rushed home to try it out. I wrote a few tests. I did a little TDD. And I hated it.
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. ¯\_(ツ)_/¯
I know I'm wrong
I just don't know what I'm wrong about. Obviously.
What imposter did this?
Have you ever suffered from imposter syndrome? Have you also ever thought "what idiot did this?"
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.