Coverage gaps tend to hide in exactly the code you are about to change. vg tests finds them and helps you close them with a tightly scoped test run. This guide walks through surfacing gaps with --missing and running the minimal test set with --run and --exec.
Overview
vg tests maps tests to code using the code map — it knows which tests reach a node by call or coverage linkage. From that mapping it can show what is covered, what is not, and the smallest command that exercises the relevant tests.
Prerequisites
Build a code map:
vg build
Step 1 — See what covers a node
vg tests
This lists the tests linked to the node so you know what already exercises it.
Step 2 — Find the gaps
Surface untested nodes near the one you are working on:
vg tests --missing
These are the gaps that matter most right now — code adjacent to your change that nothing tests. Prioritize writing tests for these before shipping.
Step 3 — Run only the relevant tests
After adding or updating tests, validate with a scoped run instead of the full suite. Print the minimal command:
vg tests --run
Or execute it directly:
vg tests --exec
This gives you fast, targeted feedback on exactly the code you touched.
Step 4 — Tie gaps to risk
Combine coverage analysis with impact analysis. When you assess what a change could break, surface the tests to run for that blast radius:
vg impact
Nodes that are both high-impact and untested are your top priority — high reach, low safety net.
Making it a habit
Before opening a pull request, run vg tests --missing around your changes and close the gaps that matter. Over time this steadily raises coverage where it counts without forcing exhaustive suites everywhere.
Related
- Map tests to code with
vg tests. - Estimate blast radius with
vg impact. - Inspect a node with
vg show.
Test mapping is computed locally from the code map.