Confidence in Code That Runs Unattended

Unattended code needs different testing

A web application has users who report problems. A service running overnight has nobody watching, which means its failure handling matters more than its normal operation.

The question is not whether it works with good input. It is what happens with the record that has a null where a date should be, at three in the morning.

What to test

1. Transformations — the logic that turns input into output
2. Boundaries — what happens with empty, huge, malformed input
3. Failure paths — external service down, timeout, bad response
4. Idempotency — running the same thing twice
5. Reconciliation — the counts add up

Test against real data shapes

• Use anonymised production samples, including the awkward ones
• Include the record that broke it last time
• Test with an empty input set
• Test with a volume larger than you expect
• Test with a deliberately corrupted input

Synthetic clean test data tests the code you wrote against the assumptions you made, which is the least useful thing to verify.

Mock the boundary, not the logic

Run them automatically

Tests that require someone to remember stop being run. They should execute on every push, with a visible result, blocking a merge on failure.

That is a day of setup and it is what turns a test suite into a working safety net rather than a good intention.

Frequently asked questions