Sharp Testing

A test earns its place by detecting a plausible mistake that no other check detects. The default for a change is no new test.

When a test is justified

A permanent test answers: which plausible mistake would it catch, which existing check would miss it, and why would the mistake matter. Name the incorrect behavior and its consequence; that the code could change is no answer. Inspect the relevant tests first, and extend one when it can cover the missing case.

New functions, branches, files, and uncovered lines call for no test by themselves. Coverage locates gaps; it never justifies a test. Getters, pass-through code, constructors, type-level guarantees, and framework behavior need no test. A change with no new test is valid when existing protection suffices.

Expected values

Expected values come from the requirement: the domain rule, the specification, the compatibility obligation. The implementation shows what the code does, never what it should do.

An expectation generated with the code under test, or copied from its output into a snapshot, fails only when the code changes. That is a change detector, not a guard. Validate a captured output against the requirement before adopting it as a fixture or a snapshot.

What to assert

Assert behavior: computed results, selected data, state changes, emitted events, access controls. Leave incidental fields, helper calls and internal ordering unconstrained. A behavior-preserving refactor leaves assertions intact.