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.
