Test

Test

Write or strengthen tests for a named behavior. Use existing tests directly when the task is only to run a known suite; this skill is not a required wrapper. A test is useful when it distinguishes an accepted outcome from a plausible failure, not merely when it executes the implementation. A green test is evidence for the caller's decision, never the test author's merge approval.

Modes

Default to generate; mode and scope are skill prompt choices, not invented CLI flags. Coverage thresholds come from the caller or repository.

Critical Constraints

• Assert the promised effect. Check the state change, stored record, outbound call or count the behavior promises, with exact expected values. A status code, a returned object or the absence of an exception alone does not prove the behavior.
• A regression test proves nothing until it fails on the defect. Show that it fails on the pre-fix code (see Mutation-kill proof). Until then, report its proof as "not shown"; green alone is not yet proof.
• Derive cases from accepted observable behavior; reuse examples from the conversation, bead, specification or existing contract before inventing new ones. Keep established domain names; do not unify bounded-context terms by renaming tests.
• Use the repository's framework and real check recipe; keep tests free of accidental timing, ordering and shared-state dependencies.
• A test that starts green on existing correct behavior is legitimate. Never manufacture a RED claim or alter acceptance to excuse a product defect.
• Repair a discovered defect when already authorized; otherwise report the reproducer and finding. Do not mask it by deleting or weakening a test.