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.

Would you rather Test-First, or Debug-Later?

– Robert Martin

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

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
  • Pressing reload and compile and 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!