Automated testing for small teams

The gap between knowing this and actually doing it is where most teams lose ground. Most advice about automated testing assumes a team that does not exist at your size. Here is the version that does not.

Code gets read far more often than it gets written, and usually by someone with less context than the author had. Assume whoever inherits this will have half your context and none of your patience.

What to keep

Tests are how you change things without fear. The teams that handle this well are rarely the ones with the biggest budgets. The version that survives contact with a real deadline is the simple one.

What to drop

Process that exists to coordinate ten people is overhead when there are two of you. Small and consistent beats large and occasional here.

How to approach it

A slow test suite is a suite nobody runs. Small and consistent beats large and occasional here. The failure mode is not doing it wrong, it is doing it once and assuming it stays done.

How to tell if yours is fine

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
• 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.