Test writing

Write each test against a bug it would catch, in the repo's own suite, and watch it fail before trusting it. Driving new behavior test-first is its own step; this skill is how any single test is written, and the whole job when the code already exists.

Workflow

1. Name the bug. State the regression or wrong input the test would catch. If you can't name one, don't write the test.
2. Read the existing suite. Use its runner, layout, fixtures, helpers, and naming. Add a new helper or fixture only when none fits.
3. Pick the lowest level that observes the behavior through the interface its caller uses. Go up a level only when the behavior lives in the wiring between parts.
4. Write it. One behavior per test, named for that behavior in plain terms.
5. Prove it can fail, as proven able to fail in principles says: watch it go red for the reason named in step 1, then pass on the change. A test that passes either way documents the behavior without holding it.
6. Run the repo's own check — what CI runs, or its test, typecheck, and lint scripts when there is no CI. Report any test that could not be run, and any failure unrelated to the tests as separate from them.

Existing behavior

Before a refactor, pin what the code does now, including behavior that looks odd.

When current behavior looks like a bug, ask before any test encodes it as expected, and never fix it inside a test change. With no one to ask, leave it untested and report it with the input that shows it.