Skip to content

1 min read

Tests that leave evidence

Sovica Engineering Quality

Table of Contents

A test that passes because a dialog said “Not allowed” proves that a dialog said so. It doesn’t prove the rule ran, or that the happy path checked anything at all. We’d rather have the code tell us what it decided.

Code records its decisions

Next to the checks whose failure would hurt (medical-legal rules, money, double-booking and holds), the code writes a small record:

recordEvidence(ctx, 'ML-23', {
  verdict: outside.length ? 'blocked' : 'ok',
  reason: outside.length ? 'face_to_face_missing' : 'face_to_face_recent',
  facts: { prescriptionId: row.id, drugIds, windowDays: 90, daysSinceSeen },
});

The spec id is the requirement’s own id, as used in test names.

Verdicts are ok, blocked, violated (the rule isn’t met, but policy lets the action go ahead) and skipped. Both outcomes get recorded, so a test can prove the check ran when nothing went wrong.

Outside the database, on purpose

Evidence isn’t written to the database. A blocked record therefore survives the rollback of the transaction it stopped, which is exactly when you want it. It also does no queries and never changes behaviour: the existing throw stays where it was.

No patient data, enforced

A record holds only ids, codes, counts, flags and money in minor units. The schema refuses fact keys such as clientName, noteText or dateOfBirth, while keys ending in Id or Count pass.

Pruning what doesn’t earn its keep

Tests cost attention, so pnpm test:audit looks for the ones that don’t pay it back: skipped tests, files with no assertion, tautological asserts, and evidence asserts for a spec id the code no longer records. It also lists invariants the code records that no test proves, so the gap shows up in both directions.

1,903 pull requests merged in the past year

Ready to redefine how the world’s clinics run?

Careers at Sovica