Knowing what a change affects is useful; knowing which tests prove it still works is actionable. The --tests flag on vg impact surfaces exactly the tests to run before you ship.
Why test impact matters
Running the entire test suite on every change is slow, and skipping tests is risky. Test impact gives you the middle path: from the blast radius of your change, it identifies the tests that actually exercise the affected code so you can run a focused, relevant subset.
Prerequisites
Build the graph so impact and test linkage reflect current code:
vg build
Run impact with tests
vg impact --tests
Instead of only listing affected nodes, the output surfaces the tests tied to those nodes — the ones worth running before merging.
How to act on it
- Make your change.
- Run
vg impact --teststo see the relevant tests. - Run that focused set and confirm they pass.
- Ship with confidence that the affected paths are covered.
When coverage is thin
If impact analysis affects code with few or no associated tests, that is a signal in itself: the change touches under-tested territory. Treat that as a prompt to add tests before shipping. The broader Vibgrate Graph tooling can help you find which nodes are covered and which are not.
Combine with the full blast radius
Run the plain command first to understand reach, then add the flag to get the test list:
vg impact
vg impact --tests
Related
See the companion articles on impact analysis before a change and interpreting impact output for the full picture.