Impact Analysis Testing
How NeoArc Studio verifies that architectural changes correctly propagate across all node types and edge types in the Intent Graph, with automated tests covering every cross-domain scenario.
The Scale of the Problem
Architecture governance depends on accurate impact analysis. When a model entity is renamed, the system must identify every schema that derives from it, every API endpoint that references those schemas, every diagram that visualises the entity, every graph view that includes it, and every documentation page that describes it. Missing any of these connections means the architect proceeds without full awareness of the consequences.
The Intent Graph in NeoArc Studio spans model entities, schemas, REST endpoints, GraphQL operations, AsyncAPI channels, webhook configurations, diagrams, graph views, ERD views, search views, ADRs, and documentation pages. Impact analysis must work correctly across all of them, including multi-hop paths where a change ripples through several intermediate constructs before reaching its full extent.
Test Suite Structure
The Intent Graph service test suite contains automated tests organised into integration-style describe blocks. Each test constructs a realistic graph fragment, triggers a change on a source node, and asserts that the correct set of downstream nodes appears in the impact result. These are not unit tests against isolated functions. They exercise the full graph build, edge registration, and traversal pipeline.
| Test Category | Test Count | What It Verifies |
|---|---|---|
| Cross-Domain Impact Analysis | 19 | Changes to any construct type propagate through all connected edge types to every downstream dependency |
| Edge Type Coverage | 24 | Each edge type is individually verified to participate in impact traversal |
| Node Type Registration | 2 | All node types are recognised by the graph builder and correctly registered |
| Edge Cases | 12 | Orphaned nodes, circular references, deep chains, hub nodes, and deduplication |
| Content Traceability Impact | 13 | Documents edge traversal, auto-binding, scope filtering, and staleness detection |
| Graph View and ERD Impact | 15 | Model-derived views correctly receive impact from underlying entity changes |
| API Protocol Coverage | 28 | REST, GraphQL, AsyncAPI, webhook, and MCP constructs all participate in impact analysis |
| Governance and Reporting | 18 | Drift detection, compliance bindings, and report data sources respond to structural changes |
| Multi-Hop Traversal | 30 | Changes propagate through chains of 3 or more intermediate nodes to reach all affected constructs |
Cross-Domain Impact Analysis
The most critical category verifies that changes cross domain boundaries correctly. A model entity exists in the data modelling domain. When it changes, the impact must cross into the schema domain (schemas derived from the entity), the API domain (endpoints referencing those schemas), the visualisation domain (diagrams and graph views depicting the entity), the governance domain (drift detection and compliance bindings), and the documentation domain (pages with documents bindings to the entity).
Each of the 19 tests in this category constructs a multi-domain graph and verifies that the full downstream set is returned. These tests are parameterised across construct types, so the same traversal logic is verified for model entities, schemas, endpoints, graph nodes, and ADRs as change sources.
Edge Type Coverage
The edge type tests form the foundational layer of the test suite. Each test is deliberately minimal: two nodes connected by a single edge. One node is marked as changed. The test asserts that the other node appears in the impact result. This isolation guarantees that the traversal engine recognises and follows each edge type independently of any other graph structure.
The tested edge types include derives-from, references, visualises, documents, implements, governs, binds-to, and others covering every relationship in the Intent Graph specification.
Edge Cases That Break Naive Implementations
Graph traversal has well-known failure modes. The edge case tests verify that the Intent Graph handles all of them correctly.
Content Traceability Testing
The 13 content traceability tests verify that documentation staleness detection works end-to-end. These tests build graphs containing pages with documents edges pointing to architectural constructs, then trigger changes on those constructs and verify that the pages appear in the impact set.
Specific scenarios tested include auto-binding creation from content block signals (when a page contains a diagram viewer or schema link block, the binding is inferred automatically), manual binding traversal, scope filtering based on traceabilityCoverageScope configuration, and the interaction between documents edges and other edge types during multi-hop traversal.
What the Tests Prove
Taken together, these 161 tests establish several guarantees that underpin the reliability of architecture governance in NeoArc Studio.
| Guarantee | How It Is Verified |
|---|---|
| No edge type is silently ignored | Each edge type has a dedicated test that fails if traversal skips it |
| Cross-domain changes propagate fully | 19 tests verify that changes cross every domain boundary in the system |
| Cycles do not cause infinite loops | Circular reference tests complete within the test timeout with correct results |
| Deep dependency chains are followed | Multi-hop tests verify propagation through 4+ intermediate nodes |
| Documentation staleness is detected | Content traceability tests verify that documents edges participate in impact analysis |
| Results are deduplicated | Tests with diamond dependency patterns assert exactly one entry per affected node |
| New node types are registered | Registration tests fail if a node type is added without Intent Graph registration |
Engineering Rigour, Not Marketing
These tests exist because impact analysis is foundational infrastructure. If it fails silently, architects make decisions based on incomplete information. Schemas break without warning. Documentation drifts without detection. Governance reports show false confidence. The test suite is not a feature to advertise. It is the engineering discipline that makes every other feature trustworthy.