A practical checklist for automated testing
There is no clever trick in this one, just a handful of decisions worth making deliberately. Run through this the next time automated testing comes up.
Code gets read far more often than it gets written, and usually by someone with less context than the author had. The teams that stay on top of it are the ones who put it on a calendar rather than a wish list.
The checklist
- Tests are how you change things without fear
- Cover the paths that lose money if they break
- A slow test suite is a suite nobody runs
- Someone is named as the owner
- There is a date to review it again
What it costs to ignore
Tests are how you change things without fear. Small and consistent beats large and occasional here. Budget a little time for it every quarter and it never becomes a project of its own.
What this looks like day to day
The question is rarely whether something can be built, but what it costs to keep running afterwards. Three things worth confirming about automated testing before you move on:
- Someone can say what the current setup is without going to look
- Tests are how you change things without fear — and you know whether that is true here
- There is a way to tell whether the last change to this helped
Pick the one that would hurt most if it failed, and start there.