Assess the impact of a change (ripple analysis)¶
A diff tells you what changed. Impact analysis tells you what the change can reach — the entities that were edited plus the entities that depend on them and might now behave differently. That second set is the blast radius you actually have to review and re-test.
Understand builds this from two things it already has: an exact list of what changed between two versions, and the cross-references that show how the code is wired together.
1. Find what changed¶
Point Understand at a comparison database — an earlier .und or a specific Git commit — and open
the Changed Entities Locator (Compare → Locate Changed Entities). It lists every Added,
Removed, or Changed entity with line-churn columns and metric deltas. Setting this up is
covered in Compare two versions of a project.
This is your set of directly changed entities.
2. Follow the ripple outward¶
For each changed entity, the code that can be affected is the code that uses it. Trace it with the same cross-reference tools you use to explore:
- Callers / called-by — open a changed function's Butterfly or Call graph in its Compare variant to see what invokes it, transitively, against the other version — most default graphs have a Compare variant like this. See the graph catalog for the full list.
- Dependents — for a changed file or component, list what depends on it with Browse & export dependencies.
- References — right-click a changed variable, type, or macro and use the Information Browser to see every place it is read or written.
- Change Impact report — the Change Impact interactive report lists the entities impacted by changing a given function (its callers, and their callers, to a chosen depth) — a ready-made ripple list. See the report catalog for the other reports that can support the review.
The union of the changed entities and everything reachable from them is the potentially-affected set.
Not every dependent is truly affected
Reachability is a superset — it is deliberately conservative. A change that only touches an internal detail (say, a value that never crosses an interface) ripples less far than the graph suggests. Use the ripple to decide where to look, then confirm real impact by reading the code.
3. Bound the blast radius¶
Turn the two sets into a reviewable scope:
- Visualize the churn with the Changes Treemap to see where change concentrated.
- Quantify it — the Changed Entities Locator and
und export -changesexposePercentChangedandDiff-prefixed metric deltas (DiffCyclomatic,DiffCountPath, …), so you can flag changes that also made an entity more complex. See Export & track metrics over time.
4. Feed it into testing¶
The affected set is exactly what a risk-based test plan needs — see Prioritize testing from code changes.
Where to next¶
- Compare two versions of a project — set up the comparison first.
- Where did the churn happen? (Changes Treemap).
- Prioritize testing from code changes.