maintainable-tests
maintainable-tests
Write, edit, refactor, and review tests so a developer returning months later can understand the behavior, the edge cases, and the reason each important test exists.
Passive Trigger
Load this skill in the background whenever the task involves automated tests, examples used as tests, fixtures, mocks, stubs, fakes, test data builders, regression coverage, characterization tests, flaky tests, or production-code changes made to improve testability. Keep it lightweight for small edits: apply the core rules silently, then mention only the test-design decisions that affect the final implementation.
Decision Tree
Consult the relevant reference only when a non-obvious test-design decision needs more detail than these rules or local examples provide. A matching topic does not require a reference read.
-
Adding tests for new behavior: Name each test after the user-visible rule or domain invariant, then use concrete examples that teach the behavior. Consult
references/principles.mdorreferences/naming-and-intent.mdif intent is unclear. -
Fixing a bug or adding regression coverage: Prove the broken scenario and expected behavior, reusing adequate coverage where it exists. Consult
references/legacy-and-characterization.mdwhen preserving legacy behavior or explaining uncertainty needs care.