I can still remember the first time I tried Test Driven Development (TDD).
At the time, it took a lot more finagling to get Tests to work; and that didn’t help the giant, crushing, feeling of inadequacy I felt.
I was working at a great company in the DC area with a well-respected tech team, and they were rah-rah XP and Scrum; with XP practices such as Pair programming and TDD headlining their efforts.
When you go into a situation where everyone around you is used to doing a thing and you’ve never seen it before… let’s just say I was pretty scared. Today we know it as ‘imposter syndrome’ but back then I was just… scared.
And then we started using TDD. My Pair said, “Ok, make the tiniest change you can make to pass this test”. I can’t remember it exactly, but it was something along the lines of returning the correct quote type (an enumeration) based on the request, and so I started to figure out what sort of behavior it’d need in different circumstances, and wrote way more code than I needed to.
My pair politely said, “stop. Literally write the simplest code that passes this test.” and he politely wrote something like,
return 42;
I was… aghast. How the heck was this useful? We certainly wouldn’t go to production with “return 42;” in our code base, right? As I’d later find out, of course not — but TDD wasn’t the practice of writing the end result first; it is the practice of discovering and discerning the end result through small incremental steps that provide confidence with every evolution.
I went home that night unsure if I’d ever use TDD again. It didn’t seem like it accomplished much, and it seemed too simple to help make better software.
Next time I’ll talk about Day 2: The Tests Strike Back