Getting started with automated testing
Most teams know this matters. Fewer have decided who owns it. A short on-ramp to automated testing for teams who have not touched it before.
Most development decisions are really maintenance decisions wearing a different hat. The teams that stay on top of it are the ones who put it on a calendar rather than a wish list.
Why this earns attention
Tests are how you change things without fear. None of that requires a large budget, only a decision and someone to own it. Most teams find the first pass takes an afternoon and the maintenance takes minutes a month.
Your first week
- Find out what is already in place
- Cover the paths that lose money if they break
- Change one thing and measure it
A slow test suite is a suite nobody runs. There is a version of this that is over-engineered, and it is worth avoiding. Write the reasoning down alongside the decision, because the reasoning is what changes first.
In practice
Code gets read far more often than it gets written, and usually by someone with less context than the author had. Three things worth confirming about automated testing before you move on:
- Someone can say what the current setup is without going to look
- Cover the paths that lose money if they break — and you know whether that is true here
- There is a way to tell whether the last change to this helped
None of this needs a rewrite. Most of it is a morning's work once someone decides to do it.