Finding and Closing Test Coverage Gaps with vg tests

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.