etiquetteAutomated tests help us write code faster. Unit tests immediately tell us when we break something. Integration tests calm us down, reducing the fear of shipping a failure to a user. But who are “us”? Programmers. What about our employers? How do automated tests help them? Automated tests protect their investments.
Every change we make to a codebase costs our employer money. Whether they pay us monthly or per line of code, the bottom line is the same: it’s the code that reaches the repository and is eventually released to the end user.
That’s what the business is investing in—new features or bug fixes. The code that’s written and shipped is what matters to them.
Even when they say they’re investing in people, what they really want is the code. People are merely an intermediate by-product. The ultimate asset is the codebase.
They want to protect that asset.
A loss of investment could be a hundred lines written today not working tomorrow. Think about it this way: we expect a car to work after paying the body shop to fix it. We don’t mind paying again if something else breaks—but not if it’s the exact same part they fixed yesterday. We expect the repaired part to function properly while driving. We want a warranty on what’s already been fixed.
Similarly, our employers expect our code to work once we’ve committed it and collected our paycheck. They want a warranty that the code won’t break again once it’s been fixed. Automated tests can offer that warranty.
Continuing the metaphor: “driving” a codebase means actively modifying its parts—refactoring or extending. The more aggressively we drive it, the higher the risk of breaking something. The parts of the code not covered by tests are the first to break.
Test coverage guarantees that what worked before—and was already paid for—continues to work even under the stress of refactoring.
So, any contribution to a codebase without a supporting test is a waste of the employer’s money.
