Test Design

A test earns its place by catching a behavior break that a user of the code would notice. Match the check to the changed behavior and the cost of running it. Follow the repository's test runner, layout, and naming before applying the fallbacks here.

Decide whether a new test earns its place

Do not add a test to raise a coverage number, to mirror the existence of a function, or to satisfy a workflow step. Add one when a cheap test path reaches the changed behavior: an existing unit, component, integration, or regression suite that already exercises that code path.

Prefer no new test over a bad one. When a focused test would need broad harness setup, brittle mocks, production-only state, timing-dependent waits, or large unrelated fixture churn, use the closest executable check instead, such as a targeted script, a real command, browser automation, a snapshot comparison, or a log assertion, and say which one you used.