What this prompt does
This prompt analyses test coverage gaps in a [language]/[framework] project, moving from your [current_coverage]% toward a [target_coverage]%. Instead of raising the number blindly, it ranks uncovered code by risk (business criticality times complexity), categorises gaps as completely untested, partially tested with missing branches, or edge cases, and generates tests for the top [priority_count] highest-risk areas. Each generated test comes with an explanation of the risk it mitigates.
It works because coverage percentage alone is a vanity metric — what matters is whether the risky paths are protected. By pasting your real [coverage_report], the AI grounds its ranking in actual data, flags dead code inflating the uncovered count, and configures thresholds in [test_framework] to prevent regression. It tunes coverage collection to exclude [exclude_patterns] so the number reflects code that benefits from tests, and drafts a sprint plan to reach [target_coverage]% within your [timeline], complete with badges and PR checks.
When to use it
- Inheriting a low-coverage codebase and wanting to raise it where it actually matters
- You need to rank coverage gaps by business risk, not just by file
- You want tests generated for the riskiest untested paths first
- Distinguishing real gaps from dead code that merely inflates uncovered lines
- Setting
[test_framework]thresholds to stop coverage from sliding back - Planning a realistic path to
[target_coverage]% over a defined[timeline]
Example output
You get a prioritised analysis: uncovered files and functions ranked by risk, gaps categorised (untested, missing branches, edge cases), generated tests for the top [priority_count] areas each with the risk it mitigates, a list of dead code safe to exclude or remove, threshold config for [test_framework], coverage-collection tuning that excludes [exclude_patterns], guidance on branch versus line coverage for a [project_type], a sprint plan to hit [target_coverage]% in [timeline], and badge/PR-check setup.
Pro tips
- Paste a real
[coverage_report]; without actual data the ranking is guesswork and the sprint plan won't reflect your codebase - Set
[target_coverage]to a sustainable number — 80% is a common bar, and chasing 100% usually means testing trivial getters - Exclude the right things via
[exclude_patterns](migrations, config, generated files) so the percentage reflects code that benefits from tests - Trust the risk ranking over raw file order; a complex billing function deserves tests before a simple presentational helper
- Use
[priority_count]to focus effort; generating ten high-risk tests well beats a hundred shallow ones that assert little - Configure thresholds in
[test_framework]once you hit a level, so coverage can't silently regress on the next pull request - Remove or exclude genuine dead code rather than testing it, since writing tests for code nobody calls just inflates the number without reducing risk
- For an API
[project_type], lean on branch coverage over line coverage since untested conditional paths are where bugs hide
