Boxers jump rope, stretch, shadow box, spar, and just stay in top physical shape so they can perform their best when it’s time for Fight Day. As a programmer, our Fight Day is writing quality production code and shipping it without bugs. When I hear complaints about not wanting to write tests for production code, it sounds a lot to me like a professional boxer saying they don’t want to jump rope.
It’s fine if you’re just at home, playing around, throwing a few punches with friends. But when you’re serious about building real products and shipping code that provides value to your users, I highly recommend writing tests to exercise and validate your code.
Bad reasons to write tests
- My boss told me to do it
- CI won’t pass my PR without enough coverage
- I’m told I’m supposed to do it (like flossing)
Bad reasons not to write tests
- I have to write more code
- Consider this: does a boxer complain that she has to throw more punches? Isn’t part of what you enjoy doing as a programmer writing code?
- It’s hard
- So was learning
vi, and yet somehow you’re a wizard at that now; as with anything new, it’s hard when you start, you practice more, and it gets easier and you become better at it
- So was learning
Good reasons not to write tests
- We’re building a very early prototype that we don’t plan to bring to production
- This can be a tricky line to draw. Going back to the boxing analogy: are you just playing around, practicing, learning, and sparring right now? Or will the code you’re writing be used for Fight Day?
- We don’t care about stability in our code
Good reasons to write tests
- We found a bug, and I need to exercise it
- A bug likely means there was a shortcoming in your understanding of the system, and if you failed to understand it then there’s a high chance others in the future will as well
compileand clicking around to verify code works properly is tedious
- I’m a pretty good programmer, but I know I’m not perfect
- I want to be a better programmer; I want to write better code
- I want to communicate better with my teammates
- Large systems are complex, and I don’t have the capacity or trust in my brain to hold the entire system in my mind to understand how my changes impact other parts of the system
- Specs keep on changing from under me, and it’s difficult to keep track of it all; I want to ensure our production code is matching some defined specification even if it’s in flux
- I feel more confident when making upgrades to dependencies: deprecation warnings are visible during test runs
- My future self (and teammates) will benefit from the investment I make in our code base today
- It’s fun!
Did you find this helpful? Get updates when I post more like this by subscribing to the Nerd Tower newsletter.