Automated testing: what to get right first

We end up explaining this on discovery calls often enough that it deserved writing down. If you only fix one thing about automated testing this quarter, make it the first item below.

Code gets read far more often than it gets written, and usually by someone with less context than the author had. Write the reasoning down alongside the decision, because the reasoning is what changes first.

Start here

Tests are how you change things without fear. That sounds obvious written down. It is still the thing most often skipped. It is worth deciding this deliberately rather than inheriting whatever the last person set up.

Then this

Cover the paths that lose money if they break. There is a version of this that is over-engineered, and it is worth avoiding. The practical test is whether someone new to the project could tell, in a minute, that it had been handled.

Eventually

A slow test suite is a suite nobody runs. It is worth being explicit about, because assumptions differ quietly. The version that survives contact with a real deadline is the simple one.

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
• A slow test suite is a suite nobody runs — 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.