Testing should prove the changed behavior, not just inflate coverage.
- Test the behavior that changed.
- Prefer fast tests close to the changed logic.
- Add broader integration or end-to-end coverage when the risk crosses boundaries.
- Mock external systems, not the behavior under test.
- Keep tests deterministic and side-effect-safe.
Coverage is a guardrail, not the goal.
Use thresholds if the repo needs them, but do not confuse line coverage with confidence. A smaller number of targeted tests is better than broad but shallow assertions.
Always consider tests for:
- public interfaces
- business rules and state transitions
- edge cases and invalid inputs
- failure paths and recovery behavior
- security-sensitive logic
- automation scripts that transform or move important data
For scripts, agents, and pipelines, prefer some combination of:
- unit tests for parsing or decision logic
- dry-run modes
- fixtures or golden files
- temp-directory integration tests
- explicit assertions that tracked runtime state is not mutated unintentionally
| Change type | Minimum expectation |
|---|---|
| pure logic refactor | existing tests still pass, add unit tests if behavior was untested |
| new feature | tests for the new behavior and main failure mode |
| bug fix | regression test that would have caught the bug |
| workflow or policy change | validation command or fixture proving the new rule |
| external-state automation | dry-run and temp-path validation |
- keep fixtures minimal
- name tests by behavior
- reset mocks and temp state between tests
- never depend on production data
- avoid flaky network-dependent tests in PR-required CI
A PR should not rely on reviewers to imagine the test plan. State what was validated and why that level of validation is sufficient.