Reasons for testing code

3-minute read
software development

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!