- test-coverage-loop.md 42 lines · 2.0 KB
Test Coverage Loop
Loop Engineering — a recurring goal that drives the agent to grow real test coverage incrementally instead of in one risky batch.
🎯 Goal
Raise test coverage toward a defined target by adding meaningful tests for the least-covered, highest-risk code first — never gaming the metric with empty assertions.
⏱️ Schedule
Suggested interval: 20m.
▶️ Run it
/loop 20m "Measure current test coverage. Pick the lowest-covered, highest-risk module and add real, behavior-focused tests for it. Re-run the suite. Continue until coverage is at least 90% with everything passing."🔁 Iteration steps
- Perceive — run the coverage report and rank uncovered code by risk.
- Reason — identify branches, error paths and edge cases that lack tests.
- Plan — choose one module/area to cover this pass.
- Act — generate tests with
test-automator+/generate-tests. - Observe — re-run
/test-coverage; if the suite is green and coverage rose, continue; if flaky, fix before moving on.
🛑 Stopping condition
Coverage ≥ target, full suite passes, and no newly-added test is flaky.
🧩 Referenced components
agent:performance-testing/test-automator— authors the tests.command:testing/test-coverage— measures progress each pass.command:testing/generate-tests— scaffolds new test cases.
💡 Example
Starting at 61%, the loop targets the untested error branches of the payment module first, climbing a few points per pass until it crosses 90% with a green suite.
Scanned by NVIDIA SkillSpector
Automated static analysis (no LLM) · v2.12.0 · 2026-10-17
SkillSpector looks for patterns such as shell commands, credential access, network calls or unpinned dependencies. An observation is something worth reading in the files before you install, not a confirmed vulnerability. Components that run code locally, like hooks, MCP servers and security tooling, naturally show more of them.
No observations.
Learn more about NVIDIA SkillSpector or how components are reviewed.