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 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 about what to test. The tests improve. The pain persists. A change to a business rule breaks seventeen tests, most of which are not about business rules. An integration test requires spinning up four services to assert one value. An end-to-end test passes in isolation and fails in CI for reasons nobody can reproduce. More coverage, more pain.<\/p>\n\n\n\n
The problem is structural, not methodological. The tests are not wrong. The structure the tests are attempting to exercise is wrong. Components have absorbed responsibilities they should not have. Dependencies are hidden rather than declared. Boundaries have been drawn in the wrong place, or not drawn at all. No amount of better tooling, higher coverage requirements, or more disciplined test writing fixes a structural problem. Fix the structure; the tests follow.<\/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 of the spiral 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 role 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 In a system with no meaningful component boundaries, unit scope and system scope are the same thing. There is nothing below the full system that can be isolated. The spiral collapses into E2E by default, because E2E is the only level at which anything coherent can be exercised.<\/p>\n\n\n\n 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 to make it so. 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 The inverse is equally true. A component that cannot be unit-tested without mocking half the system is not badly tested \u2014 it is badly structured. The test difficulty is diagnostic. It reveals that the component has absorbed responsibilities it should not have, or that its dependencies are implicit rather than declared, or that the boundary between it and its collaborators has been drawn in the wrong place.<\/p>\n\n\n\n This is why the structural models defined in VBD and EBD are also testing models. The same role taxonomy that makes components replaceable makes them mockable. The same communication rules that prevent coupling prevent test contamination. The same line that isolates change isolates test scope.<\/p>\n\n\n\n Each component role in VBD and EBD has a characteristic test profile \u2014 not assigned arbitrarily, but derived from its structural position, responsibilities, and communication rules. Every role carries unit tests. The weight and character of those tests differs by role. Integration tests arise at the seams between roles.<\/p>\n\n\n\n Engines are the most logic-dense role and the natural home of the unit test suite. An Engine encapsulates business rules: given inputs, apply policy, produce a result. It has no workflow awareness, no sibling Engine dependencies, and no reason to reach outward beyond a Resource Accessor \u2014 which it receives through an explicit, mockable interface.<\/p>\n\n\n\n This structural position is what makes Engines straightforwardly testable. Mock the Accessor, supply controlled inputs, assert on the output. The Engine’s communication constraints ensure there is nothing else to mock. The test scope is exactly the Engine and nothing more. Every business rule, every policy variant, every edge case and failure mode belongs here \u2014 and each one is fast, isolated, and cheap to run.<\/p>\n\n\n\n Flows in EBD occupy the same structural position as Engines in VBD. A Flow receives shared state from the Experience, steps through Interactions, and emits a completion event carrying accumulated state upward. Its rule against calling sibling Flows and its prohibition from making direct backend calls keep the unit scope tight.<\/p>\n\n\n\n Mock the backend call at the Experience boundary. Simulate Interaction events through a test harness. Assert on what the Flow emits at completion, what it emits on skip, and how it handles each conditional path through its Interaction sequence. The Flow’s behavior is fully exercisable without a running backend or a real browser environment.<\/p>\n\n\n\n Managers carry unit tests, but the character of those tests differs from Engine tests. An Engine is asserting business rules \u2014 the bulk of the domain logic lives here and demands exhaustive coverage. A Manager is asserting orchestration: given this response from an Engine, did the Manager route correctly? Given a domain failure, did it handle and respond appropriately? Given multiple Engines in sequence, does it compose them in the right order with the right inputs?<\/p>\n\n\n\n Manager unit tests are comparatively fewer than Engine tests because the Manager has less behavior to assert directly. It does not compute \u2014 it coordinates. What it does assert is consequential: every state that can arrive from its collaborators, and every routing decision that follows. Mock all collaborators. Feed controlled responses representing every state each contract can produce. Verify the Manager’s decisions, not its collaborators’ behavior.<\/p>\n\n\n\n Experiences in EBD mirror Managers in VBD at the orchestration layer. An Experience composes Flows, holds accumulated journey state, dispatches to the backend, and advances the journey in response to Flow completion and skip signals. Unit tests assert journey composition logic: which Flows execute, in what order, under what conditions, and how the Experience responds to each possible signal from each Flow. The backend is mocked. Flows are mocked.<\/p>\n\n\n\n Accessors sit at the system’s external boundary. Their job is translation: convert a domain request into an external call, convert the response back. Whether the external system is reachable, whether it is correctly provisioned, whether it performs within acceptable bounds \u2014 none of these are Accessor concerns. They belong to system testing and deployment verification.<\/p>\n\n\n\n Unit tests for an Accessor verify the translation. Mock the data source driver, control what it returns, assert that the Accessor’s output matches the expected domain representation. The Accessor has no business connecting to a real database in a unit or integration test. Its correctness is about the translation. The infrastructure’s correctness is about the infrastructure.<\/p>\n\n\n\n Interactions are atomic. They render, receive user input, and emit events. They carry no flow logic, make no backend calls, and have no awareness of adjacent components. Render in a harness, simulate the input event, assert what was emitted. Props and callbacks are the entire interface \u2014 no mocks needed.<\/p>\n\n\n\n Utilities are simpler still: inputs in, outputs out, no side effects. Given input X, assert output Y. The only exception is a Utility wrapping an external sink \u2014 a log transport, a telemetry exporter \u2014 where the sink gets mocked. Everything else is pure function territory.<\/p>\n\n\n\n Select a component role to see its test level, what it validates, and what gets mocked.<\/p>\n\n\n\nTesting Is Not Separate from Design<\/h2>\n\n\n\n
\n\n\n\nTest Profiles by Role<\/h2>\n\n\n\n
Engines \u2014 The Unit Test Core<\/h3>\n\n\n\n
Flows \u2014 The EBD Equivalent<\/h3>\n\n\n\n
Managers \u2014 Orchestration Under Test<\/h3>\n\n\n\n
Experiences \u2014 The EBD Equivalent<\/h3>\n\n\n\n
Resource Accessors \u2014 Translation Under Test<\/h3>\n\n\n\n
Interactions and Utilities \u2014 Narrow and Fast<\/h3>\n\n\n\n
\n\n\n\nTest Profiles at a Glance<\/h2>\n\n\n\n