| type |
ProcessSpec |
| summary |
Defines test expectations so agents add coverage that catches regressions without duplicating confidence. |
| id |
SPEC-0026 |
| spec-status |
active |
| last-updated |
2026-04-16 |
| aliases |
|
This spec defines how a spec-driven repo expects agents and developers to add tests when behavior changes.
- prevent regressions when fixing bugs or shipping new behavior
- make test intent legible from the repository, not only from conversation
- avoid false confidence from tests that duplicate implementation details
- prescribing one test framework or assertion style
- documenting every repo-specific test helper
- Use red-green TDD when implementing or fixing behavior.
- Add a regression test when fixing a bug unless the repo already has coverage for the exact regression.
- Test behavior, not implementation details.
- Keep one concept per test where practical.
- Test names describe the reason a failure matters.
- Avoid mocking internal domain boundaries that the test is meant to validate.
- Use the repository's canonical command surface to run tests.
- Prefer lower-cost tests first, then add integration or end-to-end coverage when the behavior crosses boundaries.
- Keep fixtures and helpers readable enough that the setup still communicates intent.
- Reuse existing testing patterns in the touched subsystem instead of inventing a one-off style.
- Add specialized helpers or factories when they reduce duplication without hiding important setup.
- what additional repo-specific test boundaries should be documented here as the system grows