The app graph is a living model of your application’s user journeys, assembled
from the traces of your test runs. It answers a question a list of tests cannot:
which user-facing flows are covered, which are only partially covered, and which
have no working test at all.
The app graph is in beta and may change.
How it is built
Every run produces page states. The app graph turns those into structure without
you maintaining a map by hand:
- Each observed UI state is fingerprinted (canonical URL plus a normalized,
minhashed view of the DOM) so near-identical states collapse to one.
- A short semantic summary of each state is embedded.
- States are clustered into a taxonomy of product areas, features, journeys,
variants, and segments.
The graph is versioned and recomputed as new runs come in, so coverage tracks
the app as it changes rather than going stale.
The taxonomy
- Product area and Feature group the app by what it does.
- Journey is a user-facing flow. A journey has one or more variants (for
example, the success path and an error path), and each variant is a sequence
of segments (steps a test would walk through).
Coverage is journey-rooted: there is one row per journey and variant. A single
journey can touch several product areas and features through its segments, so
those surface as lists rather than a single column.
Coverage states
Each journey variant has a status derived from the latest runs of the tests that
match it:
| Status | Meaning |
|---|
| Covered | At least one active, passing test covers the variant. |
| Partial | An active test covers part of the variant. |
| Quarantined | Every covering test is quarantined, so it is not gating. |
| Missing | No working test. Either no test matches, or all matching tests fail. |
| Ignored | You explicitly excluded the variant. Sticky and user-set. |
When a variant is Missing, the reason is surfaced (no matching test vs. all
matching tests failing) so a failing population does not look like an untested
one.
Proposals
As runs reveal journeys the graph does not yet model, the system proposes
additions (new product areas, features, journeys, variants, or segments). You
review them in a proposals queue and approve or reject each one, so the model
stays accurate without absorbing noise automatically.