Tests as verification

Build-along · ~10 min at your own keyboard

Anything with rules - a dilution calculator, a normalisation script, a curve fitter - can carry its own tests: 'given these 3 inputs, the output must be exactly this.' Have Claude write the checks alongside the work, and every future change gets caught the moment it breaks something. A concentration that is off by a factor of ten is a hard conversation at the bench.

Your starter: Test-case sheet

Template

Make it yours: Write your three cases from your own protocol, work each answer out by hand, make case 3 a real edge for your tool, and record both runs.

TEST CASES FOR: [the tool, e.g. dilution calculator / normalisation script / export classifier]
Written by hand BEFORE the build. The tool must match these exactly.

CASE 1 - ordinary
  Input: [the exact input]
  Required output: [the exact output, with units]
  Worked out by: [hand / a second method], so the answer does not come from the tool itself.

CASE 2 - ordinary, different shape
  Input: [ ]
  Required output: [ ]

CASE 3 - edge case
  Input: [a zero, a blank, a value past a limit, a missing column]
  Required output: [an error, a flag or a labelled control - never a silent number]

RESULTS
Run 1 (as built): case 1 [PASS / FAIL], case 2 [PASS / FAIL], case 3 [PASS / FAIL]
Rule I changed: [what changed]
Run 2: case 1 [ ], case 2 [ ], case 3 [ ] - which one broke, and did it break loudly?

These cases check the arithmetic and the rules. They CANNOT ASSESS whether a rule is right for your protocol; that call is yours.

The coach checks that what you paste back is your own work. The starter pasted back unchanged won't pass.

Do this

0/4

Share what happened

Paste your 3 hand-written cases and the pass/fail results across both runs.