How to get automated testing right
The gap between knowing this and actually doing it is where most teams lose ground. The short answer to automated testing is that it is mostly a sequence of small decisions, not one big one.
Most development decisions are really maintenance decisions wearing a different hat. If it only works because one person remembers to do something, it does not work yet.
Why it matters
Tests are how you change things without fear. Small and consistent beats large and occasional here. Write the reasoning down alongside the decision, because the reasoning is what changes first.
The steps
- Establish what you have today before changing anything
- Cover the paths that lose money if they break
- A slow test suite is a suite nobody runs
- Write down the decision so the next person does not re-litigate it
A slow test suite is a suite nobody runs. It is worth being explicit about, because assumptions differ quietly. Write the reasoning down alongside the decision, because the reasoning is what changes first.
Where to go from here
How to tell if yours is fine
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
If any of that sounds like a description of your current setup, it is fixable.