Impact Analysis Testing

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 has 40 registered node types and 24 edge types. These span 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 161 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.

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 24 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 17 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.

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.