Turn coverage gaps into a prioritized test plan
Coverage percentages say how much executed. They do not say which uncovered function deserves attention first. Test Intel adds prioritization signals while keeping native coverage as the source of truth.
Context
Use this workflow after the project's own test runner has produced lcov, Istanbul JSON, or Cobertura output. Test Intel reads that artifact locally, then adds source-to-test mapping and complexity signals without replacing the runner's coverage semantics.
Workflow
1. Generate coverage
Run the project's existing test command and keep its lcov, Istanbul JSON, or Cobertura artifact.
npm test -- --coverage2. Inspect gaps
Read uncovered files, functions, lines, and branches directly from that artifact.
test-intel-report coverage/lcov.info3. Add source signals
Map likely test files and rank functions using heuristic complexity, then inspect the highest-priority candidates.
npx -y @barissozudogru/test-intel-mcp4. Review
Treat every suggestion as a review queue. Matching filenames and complexity do not prove behavioral coverage.
test-intel-report coverage/lcov.info > test-priorities.txtObserved result
A 98.42 percent covered project still contains two uncovered lines.
The published report command inspected a real lcov artifact produced by all 22 upstream tests from p-limit 7.3.1 at commit df47604.
tests 22 passed
line 98.42 percent
uncovered 13, 14
branch 12:3:0
Interpretation
Start with a function that is both uncovered and structurally expensive, then review the proposed cases against its real behavior. The priority score narrows the queue; only an executed test can close the gap.
Limitations
- Source-to-test matching does not prove that every function is behaviorally tested
- Complexity and test suggestions are heuristic signals, not semantic guarantees
- Use native coverage data as the source of truth when it is available