I always wanted to give TDD — test-driven development — a try, but I thought I could never spare the time. Gathering all the requirements upfront, writing out the tests, and then writing out the code seemed… well, a bit much. Especially during my eager-beaver cowboy code days fresh out of school.

Perhaps I have gotten better at writing tests, or maybe I’ve just matured as a programmer (probably both), but I no longer feel this way. Certainly, if building a greenfield project, I can see how it might be faster to just crank out the code. But recently I’ve found that, for complicated edge cases or for data models that are intricate and complex, I can create in 5 lines of code a use case that would otherwise take me 10 minutes and about a million clicks in the UI. The act of stubbing out the tests also primes my mind for the feature I’m about to develop, helping me to think through the different angles I need to consider.

Of course, not only is it faster, but then the test also gets to stick around as insurance against future changes as well. It’s a sort of actionable documentation for any future developer of which potholes or rabbit holes to avoid when building up in the future.

Overall, I think the cost of writing the tests first pays for itself in at least equal measure with the time you can save setting up use cases and debugging.