I haven’t told this story yet, but I probably should soon. However because it’s part and parcel of what I’m talking about today, I need to spill the lede a little bit:
Test Driven Development is not about testing.
Sorry, had to say it. It’s called Test Driven Development because you write tests to help you iterate more quickly and solidly than you otherwise might have. Since I’m doing a lot of home DIY projects, I’ll use a DIY metaphor. TDD is like the jig you create to help you hold wood in place, be it to do your own architectural shingle siding, or to automatically space studs at 16 inches and keeping them in place while driving a screw, or to ensure your door holds in place while you’re installing it. TDD are those jigs you create to be able to tell if the shiplap you’re installing is plumb and level in a 1950s home where nothing is plumb and level (I wish I could say I hadn’t personally done this for all of those projects)
One of TDD’s unsung strengths is the ability to be used to do all sorts of positive and negative testing that would have been more difficult with unit tests alone.
When I’m using TDD, I’ll often use it to send syntactically valid but domain-nonsense inputs to a method. I’ll use it to explore the bounds of a given problem by writing as many tests that test different conditions that I can think of. A TDD ‘purist’ may think of that as wasteful; but what better time to do it than before it leaves development.