Backfill unit tests for one uncovered module
A module that works and has no tests, brought up to a stated coverage threshold.
The ticket
Write unit tests for one uncovered module until it reaches the agreed coverage threshold.
Acceptance criteria
- The module reaches the stated line and branch threshold
- Tests assert behaviour, not the shape of the implementation
- Edge cases the module already handles are covered, including the error paths
- No production code changes except to make something testable, and each such change is called out
What lands as proof
The coverage report before and after, and tests that fail if the module's behaviour is changed.
Why teams defer it
- Writing tests for code that already works feels like standing still, so it loses to anything that moves a ticket.
- The module without tests is usually the one nobody wants to open, which is exactly why it has none.
Questions
- What does the agent actually change?
- The ticket is scoped to one outcome: write unit tests for one uncovered module until it reaches the agreed coverage threshold. Work that serves that outcome is in scope, and anything outside it is left for a separate ticket, so the pull request stays reviewable.
- How do I know the work is done?
- The pull request carries the evidence, not only the diff. Here that means coverage report before and after, in the pull request, so a reviewer can confirm the result without reproducing the work locally.
- How much oversight does this need?
- None is required before the run starts. Every claim this ticket makes can be checked by machine, so the agent works straight through and a person reviews the finished pull request like any other.