ia-writing-tests

• SKILL.mdcore · 5,306 bytes
• SPEC.mddoc · 4,551 bytes
• references/anti-patterns-extended.mddoc · 3,099 bytes
• references/false-pass-oracle-traps.mddoc · 9,155 bytes
• references/generated-corpus-techniques.mddoc · 2,475 bytes
• references/isolation-and-sandbox-traps.mddoc · 6,304 bytes
• references/oracle-smells.mddoc · 10,077 bytes
• references/rationalization-table.mddoc · 2,054 bytes
• references/regression-proof.mddoc · 3,066 bytes
• references/test-completion.mddoc · 3,776 bytes
• references/test-design.mddoc · 12,567 bytes
• references/test-smells.mddoc · 8,505 bytes

# Writing tests

Produce tests that prove the requested behavior and fail when that behavior breaks. Follow user scope and the repository's actual contracts; this skill does not authorize implementation, external actions, or changes to acceptance criteria.

## Procedure

1. Discover the repository's runner, pinned wrapper, configuration, neighboring tests, and CI command before writing tests. Learn both focused and full-suite commands. Use project tooling rather than a global default; keep tracked scripts portable and apply personal wrappers only to the outer invocation.
2. Derive cases from user requirements, implemented behavior, and claims intended for the handoff. Map each acceptance criterion to a discriminating case that a plausible wrong implementation fails. Name tests by observable behavior; keep one behavior per test and make fixtures adversarial on the axis under test.
3. For bug fixes with a reachable test seam, write the reproducer, observe the intended failure, apply the smallest fix, and observe green. If the actual trigger cannot be reached, follow the missing-seam rules in [test-completion.md](./references/test-completion.md). For new features, follow the selected test posture in vertical slices: default to tests-after (one small implementation slice, then its test); with an explicit test-first choice, write one test, then the minimal implementation that passes it. Repeat by slice; writing all tests first and all implementation afterward (horizontal slicing) is an anti-pattern that produces tests for imagined behavior. Refactor after green. Never alter a specification, assertion, fixture, snapshot, or expected output merely to make the implementation pass.
4. Prefer real internal objects, real temporary files, and real test databases. Mock only external boundaries, at the last owned adapter; framework-maintained fakes are appropriate where the framework recommends them. Check the real contract and side effects before mocking.
5. Assert consumer-visible outcomes rather than private structure, mock calls, or framework behavior. Include relevant boundary, invalid-input, concurrency, and failure cases. If error handling catches, logs, substitutes, or rolls back, assert its observable result as well as error visibility.
6. Prove absence/isolation assertions with a run-unique forbidden violation and observe that specific assertion fail. Confirm the control mutation actually landed and its build completed before evaluating it. Remove the control, restore the artifact, and verify green.
7. Run the narrow checks during edits and the applicable complete checks before handoff. Inspect passed/executed counts; an empty or skipped suite is not positive evidence.