Testing difficulty is architectural evidence. When a component cannot be exercised in isolation, the problem is not the tests \u2014 it is the structure.<\/p>\n\n\n\n
The test spiral \u2014 unit, integration, end-to-end, system, user acceptance \u2014 is not a testing methodology. It is an architectural map.<\/strong> Each ring corresponds to a level of architectural scope, and that scope is determined entirely by where boundaries have been placed.<\/p>\n\n\n\n Get the boundaries right and the spiral populates itself: each tier has clear targets, predictable scope, and low maintenance overhead. Get them wrong and the spiral collapses \u2014 unit tests become integration tests in disguise, E2E tests become the only reliable safety net, and the entire suite grows expensive while providing diminishing confidence.<\/p>\n\n\n\n The conventional framing of testing as a discipline separate from design produces a particular kind of pain. Teams adopt frameworks, mandate coverage minimums, and write guidelines. The tests improve. The pain persists. A change to a business rule breaks seventeen tests, most of which are not about business rules.<\/p>\n\n\n\n The reframe: a component designed around a coherent responsibility, with explicit inputs, explicit outputs, and dependencies passed rather than acquired, is inherently testable<\/strong>. No additional effort is required. The same structural choices that allow the component to change without cascading effects allow it to be tested without elaborate setup.<\/p>\n\n\n\n Integration tests verify the seams between roles \u2014 not individual components. Everything is still mocked at the external boundary. Real external systems don’t enter until E2E.<\/p>\n\n\n\n In EBD, the equivalent seam is Experience \u2192 Flow<\/strong>: does the Experience pass correct shared state, handle Flow completion and skip signals, and advance the journey correctly?<\/p>\n\n\n\n Where you place mocks tells you where your boundaries are. Where you are forced<\/em> to place mocks tells you where your boundaries should<\/em> be.<\/p>\n\n\n\n The rule: mock at the role boundary, not inside the role.<\/strong> Each component role has one natural mock point \u2014 the interface at which it hands off to the next tier. Mock that interface and nothing else.<\/p>\n\n\n\n When a unit test requires mocking more than the single boundary below the component under test, something is wrong. Either the component has absorbed responsibilities that belong at a different tier, or its dependencies are implicit rather than injected, or an Accessor is missing. Mock proliferation is always a structural signal.<\/p>\n\n\n\n The same core scenarios that validate structural boundaries in VBD and EBD are the test scenarios that matter most. Not because coverage demands it, but because scenarios that validate structural boundaries naturally exercise the most load-bearing code paths, the most significant collaborations, and the most complete representations of what the system is actually for.<\/p>\n\n\n\nTesting Is Not Separate from Design<\/h2>\n\n\n\n
Test Profiles by Tier<\/h2>\n\n\n\n
Tier<\/th> VBD \/ EBD Role<\/th> Primary Test Level<\/th> What to Mock<\/th><\/tr><\/thead> Execution<\/td> Engine \/ Flow<\/td> Unit<\/td> Resource Accessor below<\/td><\/tr> External Boundary<\/td> Accessor \/ API Accessor<\/td> Unit (translation only)<\/td> Data source driver<\/td><\/tr> Cross-cutting<\/td> Utility \/ Interaction<\/td> Unit<\/td> Nothing (pure) or external sink<\/td><\/tr> Orchestration<\/td> Manager \/ Experience<\/td> Integration<\/td> Engines mocked, Accessors mocked<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n The Three Integration Seams<\/h2>\n\n\n\n
\n
Mock Placement Is Architectural Evidence<\/h2>\n\n\n\n
Scenarios Validate Architecture and Tests<\/h2>\n\n\n\n