Version:<\/strong> 1.0<\/p>\n
\nExecutive Summary<\/h2>\n
Testing difficulty is architectural evidence. When a component cannot be exercised in isolation, when a unit test requires a running database, when a change in one module breaks tests across a dozen others \u2014 the problem is not the tests. It is the structure that the tests are attempting to exercise. The component has no coherent boundary. Its responsibilities are distributed incorrectly. Its dependencies are hidden. Tests fail not because the code is wrong, but because the code was not organized to be observable or controllable in the first place.<\/p>\n
Boundary-Driven Testing is the observation that the test spiral \u2014 unit, integration, end-to-end, system, user acceptance \u2014 is not a testing methodology. It is an architectural map. Each ring of the spiral corresponds to a level of architectural scope, and that scope is determined entirely by where boundaries have been placed. 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
The structural models defined in Volatility-Based Decomposition<\/em> and Experience-Based Decomposition<\/em> produce boundaries that localize both change and test scope simultaneously. The same line that prevents coupling prevents test contamination. The same role taxonomy that makes components replaceable makes them mockable. The same core use cases that validate structural boundaries generate test scenarios across the full spiral. This is not a coincidence. It is the intended consequence of decomposing correctly.<\/p>\n
\nAbstract<\/h2>\n
The relationship between architectural structure and testability is direct and bidirectional: clear boundaries produce testable components, and testing difficulty reveals boundary problems. Boundary-Driven Testing articulates this relationship by mapping the test spiral onto the component role taxonomy defined in Volatility-Based Decomposition (VBD) and Experience-Based Decomposition (EBD). Each role \u2014 Manager, Engine, Resource Accessor, Utility at the system level; Experience, Flow, Interaction, Utility at the UX level \u2014 has a natural test profile determined by its responsibilities, permitted dependencies, and communication rules. Mock placement, test scope, and assertion strategy follow from structural position. The spiral is a structural mirror. Difficulty at any level of the spiral points to a specific class of boundary problem \u2014 and to the structural fix.<\/p>\n
\n1. Introduction<\/h2>\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
The reframe is simple but consequential: testing is not separate from design.<\/strong> The structure of the system determines what can be tested and how. A component designed around a coherent responsibility, with explicit inputs, explicit outputs, and dependencies passed rather than acquired, is inherently testable. 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>\nThe 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. Fix the structure; the tests follow. Paper over the structure with more elaborate test scaffolding; the problem remains and compounds.<\/p>\n
Boundary-Driven Testing takes the diagnostic function of tests seriously. It maps the test spiral to the structural models defined in VBD and EBD, making explicit which components belong at which level of the spiral and why. It treats mock placement as architectural evidence \u2014 you mock at boundaries, and if you are mocking everywhere, you have too many boundaries or they are in the wrong places. And it articulates the consequence of correct decomposition: a test suite that is fast at the base, targeted in the middle, and confident at the top, maintained by the natural structure of the system rather than by constant manual curation.<\/p>\n
\n2. The Spiral Is a Structural Map<\/h2>\n
The test spiral describes a progression from the narrowest to the broadest scope:<\/p>\n
\n- Unit<\/strong> \u2014 one component, all dependencies replaced. Fast, numerous, fine-grained.<\/li>\n
- Integration<\/strong> \u2014 component collaboration across one seam, with dependencies mocked at the outer boundary. Verifies that orchestration logic and contracts are wired correctly.<\/li>\n
- End-to-End<\/strong> \u2014 a complete user flow, full stack and browser. Verifies that the system behaves correctly from the outside.<\/li>\n
- System<\/strong> \u2014 the integrated system under realistic conditions: load, failure injection, configuration variation. Verifies non-functional qualities.<\/li>\n
- User Acceptance<\/strong> \u2014 real users or proxies confirm that what was built matches what was intended.<\/li>\n<\/ul>\n
The common reading of the spiral is proportional: many unit tests, fewer integration tests, fewer still E2E, and so on. This is a useful heuristic, but it obscures the more important principle. The spiral is not primarily about proportion \u2014 it is about scope. Unit scope is a single component. Integration scope is a collaboration across one boundary. E2E scope is a complete journey. System scope is the whole.<\/p>\n
Scope is determined by architecture. Where boundaries are placed determines what constitutes a “unit,” what constitutes an “integration,” and what constitutes a “journey.” In a system with no meaningful component boundaries, unit scope and system scope are the same thing \u2014 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 you can exercise anything coherent.<\/p>\n
Figure 1a shows the five levels of the spiral from narrowest to broadest scope. Figure 1b shows how each architectural tier attracts tests at a specific level.<\/em><\/p>\nFigure 1a \u2014 The Test Spiral<\/strong><\/p>\n%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#e0e7ff', 'primaryTextColor': '#1e293b', 'primaryBorderColor': '#4338ca', 'lineColor': '#4338ca', 'background': '#ffffff', 'mainBkg': '#e0e7ff', 'nodeBorder': '#4338ca', 'edgeLabelBackground': '#ffffff'}}}%%\n\nflowchart TD\n UNIT[\"Unit\"]\n INT[\"Integration\"]\n E2E[\"End-to-End\"]\n SYS[\"System\"]\n UAT[\"User Acceptance\"]\n\n UNIT --> INT --> E2E --> SYS --> UAT\n\n<\/div><\/p>\n
Figure 1b \u2014 Architectural Tier \u2192 Test Level<\/strong><\/p>\n%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#e0e7ff', 'primaryTextColor': '#1e293b', 'primaryBorderColor': '#4338ca', 'lineColor': '#4338ca', 'background': '#ffffff', 'mainBkg': '#e0e7ff', 'nodeBorder': '#4338ca', 'clusterBkg': '#f5f3ff', 'edgeLabelBackground': '#ffffff'}}}%%\n\nflowchart TD\n MGR[\"Manager \/ Experience\"]\n ENG[\"Engine \/ Flow\"]\n ACC[\"Resource Accessor\"]\n UTL[\"Interaction\"]\n\n MGR --> ENG\n ENG --> ACC\n ENG --> UTL\n\n<\/div><\/p>\n
\n
3. Boundaries Determine Test Profiles<\/h2>\n
Each component role in VBD and EBD has a characteristic test profile \u2014 not assigned arbitrarily, but derived from the role’s structural position, responsibilities, and communication rules.<\/p>\n
3.1 Engines \u2014 The Unit Test Core<\/h3>\n
Engines are the most logic-dense tier 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 dependencies, and no reason to reach outward unless it needs data from a Resource Accessor \u2014 which it receives through an explicit, mockable interface.<\/p>\n
This is what makes Engines straightforwardly testable. Mock the Accessor, supply controlled inputs, assert on the output. The Engine’s communication constraints \u2014 no peer Engine calls, no direct infrastructure access \u2014 ensure there is nothing else to mock. The test scope is exactly the Engine and nothing more.<\/p>\n
For Flows in EBD the same principle applies. A Flow receives shared state from the Experience, steps through Interactions, makes a backend call, and emits a completion event. Mock the backend call, simulate Interaction events through a test harness, and assert on what the Flow emits. The Flow’s rule against calling sibling Flows means the unit scope stays tight.<\/p>\n
3.2 Resource Accessors \u2014 Thin Boundary, Minimal Unit Surface<\/h3>\n
Accessors sit at the system’s external boundary, and that position defines what they are responsible for testing \u2014 which is less than it might appear. An Accessor’s 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 are infrastructure concerns, and they belong to system testing and deployment verification.<\/p>\n
If an Accessor contains meaningful translation or mapping logic, that logic can be unit tested by controlling the inputs and outputs through the Accessor’s own interface. But the Accessor has no business connecting to a real database in a unit or integration test. It either connects or it doesn’t \u2014 and that is a system-level fact, not a test target. The Accessor’s correctness is about the translation. The infrastructure’s correctness is about the infrastructure.<\/p>\n
3.3 Integration Tests \u2014 The Three Seams That Matter<\/h3>\n
Integration tests in a VBD system are not about any single component in isolation. They are about the seams<\/em> between roles \u2014 verifying that the contracts components depend on are honored, and that orchestration logic matches the design. Everything is still mocked at the external boundary. Real external systems do not enter the picture until E2E.<\/p>\nThe distinction from unit tests is scope, not realism. A unit test exercises one component against mocked dependencies. An integration test exercises the collaboration<\/em> between two components against mocked dependencies at the outer edge. You care whether the wiring is correct \u2014 not whether the database is running.<\/p>\nThere are three seams worth testing at this level:<\/p>\n
Manager \u2192 Engine.<\/strong> Does the Manager invoke the Engine with the correct inputs? Does it handle every state the Engine’s contract can emit \u2014 success, domain failure, unexpected error \u2014 and route accordingly? The Engine is mocked. Feed it controlled responses representing each state it might return. Verify that the Manager’s orchestration logic handles all of them correctly. A mock Engine returning a validation failure is just as useful as a real one \u2014 what you are testing is the Manager’s response, not the Engine’s behavior.<\/p>\nEngine \u2192 Resource Accessor.<\/strong> Does the Engine correctly use the Accessor’s contract? Does it correctly interpret the states the Accessor can return? The Accessor is mocked. No database is involved. You are testing whether the Engine handles the Accessor’s interface correctly \u2014 not whether the Accessor connects to anything.<\/p>\nManager \u2192 Resource Accessor.<\/strong> Managers sometimes interact with Accessors directly \u2014 for reads that inform orchestration decisions, or for state persistence the Manager owns. Test these paths the same way: mock the Accessor, exercise the Manager’s handling of every response state the Accessor’s contract defines.<\/p>\nIn EBD, the equivalent seam is Experience \u2192 Flow: does the Experience pass correct shared state, handle Flow completion and skip signals, and advance the journey correctly? The backend is mocked. You are verifying journey composition logic \u2014 not backend behavior.<\/p>\n
3.4 Interactions and Utilities \u2014 Narrow and Fast<\/h3>\n
Interactions are atomic. They render, receive user input, and emit events. They carry no flow logic, make no API calls, and have no awareness of adjacent components. Component tests \u2014 render in a harness, simulate the input event, assert what was emitted \u2014 cover them completely and quickly. No mocks are typically needed; props and callbacks are the entire interface.<\/p>\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 (a log transport, a telemetry exporter), where the sink gets mocked. Everything else is pure function territory.<\/p>\n
\n4. Mock Placement Is Architectural Evidence<\/h2>\n
Where you place mocks tells you where your boundaries are. Where you are forced to place mocks tells you where your boundaries should be.<\/p>\n
The rule is simple: mock at the role boundary, not inside the role. 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
Figure 2 shows where mocks belong at each test level. Each diagram is independent \u2014 together they cover the full VBD test surface.<\/em><\/p>\nFigure 2a \u2014 Engine unit test:<\/strong> mock the Resource Accessor, keep the Engine real.<\/p>\n%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#e0e7ff', 'primaryTextColor': '#1e293b', 'primaryBorderColor': '#4338ca', 'lineColor': '#4338ca', 'background': '#ffffff', 'mainBkg': '#e0e7ff', 'nodeBorder': '#4338ca', 'clusterBkg': '#f5f3ff', 'edgeLabelBackground': '#ffffff'}}}%%\n\nflowchart TD\n ENG[\"Engine (real)\"]\n ACC[\"Resource Accessor (mock)\"]\n ENG -->|\"calls\"| ACC\n\n<\/div><\/p>\n
Figure 2b \u2014 Accessor unit test:<\/strong> mock the data source, keep the Accessor real.<\/p>\n%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#e0e7ff', 'primaryTextColor': '#1e293b', 'primaryBorderColor': '#4338ca', 'lineColor': '#4338ca', 'background': '#ffffff', 'mainBkg': '#e0e7ff', 'nodeBorder': '#4338ca', 'clusterBkg': '#f5f3ff', 'edgeLabelBackground': '#ffffff'}}}%%\n\nflowchart TD\n ACC[\"Resource Accessor (real)\"]\n DS[\"Data Source Driver (mock)\"]\n ACC -->|\"calls\"| DS\n\n<\/div><\/p>\n
Figure 2c \u2014 Integration tests: the three seams.<\/strong> Each seam tests one collaboration. Dependencies at the outer edge are mocked \u2014 no real external systems.<\/p>\n%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#e0e7ff', 'primaryTextColor': '#1e293b', 'primaryBorderColor': '#4338ca', 'lineColor': '#4338ca', 'background': '#ffffff', 'mainBkg': '#e0e7ff', 'nodeBorder': '#4338ca', 'clusterBkg': '#f5f3ff', 'edgeLabelBackground': '#ffffff'}}}%%\n\nflowchart TD\n subgraph seam1[\"Seam 1 \u2014 Manager \u2192 Engine\"]\n M1[\"Manager (real)\"] -->|\"invokes\"| E1[\"Engine (mock)\"]\n end\n subgraph seam2[\"Seam 2 \u2014 Engine \u2192 Resource Accessor\"]\n E2[\"Engine (real)\"] -->|\"calls\"| A2[\"Resource Accessor (mock)\"]\n end\n subgraph seam3[\"Seam 3 \u2014 Manager \u2192 Resource Accessor\"]\n M3[\"Manager (real)\"] -->|\"reads \/ persists\"| A3[\"Resource Accessor (mock)\"]\n end\n\n<\/div><\/p>\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 and the component is reaching directly into infrastructure it should not see. Mock proliferation is always a structural signal \u2014 not a testing problem, and not a problem that better mocking frameworks solve.<\/p>\n
The inverse is equally worth examining. An Engine or Flow unit test that requires no mocks is either genuinely pure-computation (rare and fine) or is only exercising the easy path through logic that silently delegates to collaborators the test never reaches. Coverage numbers tell you how many lines ran. They do not tell you whether the logic that matters was actually exercised.<\/p>\n
\n
5. The Same Scenarios Validate Architecture and Tests<\/h2>\n
VBD and EBD both use core scenarios as architectural validation mechanisms. A core use case in VBD \u2014 Process an order, Evaluate eligibility, Onboard a new customer \u2014 should be traceable through the component hierarchy without bypassing communication rules. A core user journey in EBD \u2014 Complete developer onboarding, Publish a prism, Discover a workspace \u2014 should trace through Experience \u2192 Flow \u2192 Interaction without boundary leakage.<\/p>\n
These scenarios are also 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
Figures 3a, 3b, and 3c show the same order-processing scenario at three levels of the spiral. Each level asks a different question. Each has a different scope.<\/em><\/p>\nFigure 3a \u2014 Unit: each Engine in isolation<\/strong><\/p>\n%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#e0e7ff', 'primaryTextColor': '#1e293b', 'primaryBorderColor': '#4338ca', 'lineColor': '#4338ca', 'background': '#ffffff', 'actorBkg': '#e0e7ff', 'actorBorder': '#4338ca', 'activationBkg': '#ede9fe', 'activationBorderColor': '#7c3aed', 'signalColor': '#4338ca', 'signalTextColor': '#1e293b', 'noteBkgColor': '#fef3c7', 'noteBorderColor': '#d97706', 'noteTextColor': '#1e293b'}}}%%\n\nsequenceDiagram\n participant T as Test\n participant VE as ValidationEngine\n participant PE as PricingEngine\n\n Note over T,VE: All Accessor dependencies mocked per Engine\n T->>VE: validateOrder(missingField)\n VE-->>T: ValidationFailure \u2713\n\n T->>VE: validateOrder(validOrder)\n VE-->>T: ValidationPass \u2713\n\n T->>PE: calculatePrice(highVolumeOrder)\n PE-->>T: PricedOrder(tierDiscount) \u2713\n\n T->>PE: calculatePrice(promotionOrder)\n PE-->>T: PricedOrder(promotionApplied) \u2713\n<\/div><\/p>\n
Figure 3b \u2014 Integration: Manager orchestration with mocked dependencies<\/strong><\/p>\n%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#e0e7ff', 'primaryTextColor': '#1e293b', 'primaryBorderColor': '#4338ca', 'lineColor': '#4338ca', 'background': '#ffffff', 'actorBkg': '#e0e7ff', 'actorBorder': '#4338ca', 'activationBkg': '#ede9fe', 'activationBorderColor': '#7c3aed', 'signalColor': '#4338ca', 'signalTextColor': '#1e293b', 'noteBkgColor': '#fef3c7', 'noteBorderColor': '#d97706', 'noteTextColor': '#1e293b'}}}%%\n\nsequenceDiagram\n participant T as Test\n participant OM as OrderManager\n participant VE as ValidationEngine\n participant PE as PricingEngine\n participant OR as OrderRepository\n\n Note over VE,OR: All mocked \u2014 return controlled contract states\n\n Note over T,OM: Path 1 \u2014 validation failure\n T->>OM: submitOrder(invalidOrder)\n OM->>VE: validate(order)\n VE-->>OM: ValidationFailure\n OM-->>T: Rejected \u2014 PE and OR never called \u2713\n\n Note over T,OM: Path 2 \u2014 happy path\n T->>OM: submitOrder(validOrder)\n OM->>VE: validate(order)\n VE-->>OM: ValidationPass\n OM->>PE: calculatePrice(order)\n PE-->>OM: PricedOrder\n OM->>OR: saveOrder(pricedOrder)\n OR-->>OM: orderId\n OM-->>T: OrderConfirmation \u2713\n<\/div><\/p>\n
Figure 3c \u2014 E2E: full stack, real systems<\/strong><\/p>\n%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#e0e7ff', 'primaryTextColor': '#1e293b', 'primaryBorderColor': '#4338ca', 'lineColor': '#4338ca', 'background': '#ffffff', 'actorBkg': '#e0e7ff', 'actorBorder': '#4338ca', 'activationBkg': '#ede9fe', 'activationBorderColor': '#7c3aed', 'signalColor': '#4338ca', 'signalTextColor': '#1e293b', 'noteBkgColor': '#fef3c7', 'noteBorderColor': '#d97706', 'noteTextColor': '#1e293b'}}}%%\n\nsequenceDiagram\n actor User\n participant API as API Endpoint\n participant OM as OrderManager\n participant VE as ValidationEngine\n participant PE as PricingEngine\n participant OR as OrderRepository\n\n Note over User,OR: No mocks \u2014 real stack, real data store\n User->>API: POST \/orders\n API->>OM: submitOrder(request)\n OM->>VE: validate(order)\n VE-->>OM: ValidationPass\n OM->>PE: calculatePrice(order)\n PE-->>OM: PricedOrder\n OM->>OR: saveOrder(pricedOrder)\n OR-->>OM: orderId\n OM-->>API: OrderConfirmation\n API-->>User: 201 Created\n Note over User: Assert order visible in downstream system \u2713\n<\/div><\/p>\n
The same scenario, three questions:<\/p>\n
\n- Unit<\/strong> \u2014 Does ValidationEngine correctly reject a missing field? Does PricingEngine apply the right discount? One Engine, all its rule branches, mocks for anything it depends on.<\/li>\n
- Integration<\/strong> \u2014 Does OrderManager route correctly when validation fails? Does it call the right dependencies in the right order when it succeeds? Engines and Accessor are mocked \u2014 you are testing the Manager’s orchestration logic against every contract state its dependencies can emit.<\/li>\n
- End-to-End<\/strong> \u2014 Does an order submitted through the real API surface in the system correctly? No mocks. Real behavior, real infrastructure, real assertion.<\/li>\n
- User Acceptance<\/strong> \u2014 Does a stakeholder placing an order through the application experience the outcome they expected?<\/li>\n<\/ul>\n
Each level asks a different question about the same scenario. Each question corresponds to a structural scope. The test suite is not organized around coverage targets \u2014 it is organized around the architecture.<\/p>\n
When a scenario cannot be cleanly decomposed this way \u2014 when the unit tests would require mocking the Manager, or the integration tests have no obvious boundary to stop at \u2014 the scenario is exposing an architectural gap. The fix is structural. Tests that are uncomfortable to write at a given level signal that the corresponding structural tier is missing or muddled.<\/p>\n
\n6. UAT Validates What Architecture Validated First<\/h2>\n
User acceptance testing is often treated as a separate world from the structural concerns of the preceding spiral levels. Stakeholders exercise the system. They are not concerned with Managers, Engines, or Flows. They care whether the product works as intended.<\/p>\n
But the core user journeys that structure EBD \u2014 and the core use cases that structure VBD \u2014 are precisely the scenarios that UAT exercises. The developer onboarding journey that validates EBD structural boundaries is the same journey that a UAT participant walks through. The order processing scenario that exercises VBD communication rules is the same scenario a business stakeholder confirms in acceptance.<\/p>\n
This alignment is not accidental. Both architectural validation and UAT begin from the same question: does the system fulfill its core purpose correctly? Architectural validation asks it structurally \u2014 can this scenario be traced without boundary violations? UAT asks it experientially \u2014 does this scenario produce the correct outcome for a real user?<\/p>\n
When the architecture is sound, the answers converge. Structural boundaries support real journeys without friction. UAT scenarios map cleanly onto the E2E scenarios that confirm those journeys in the automated suite. The test spiral closes: the same scenarios that entered at the unit level \u2014 as isolated assertions on Engine logic \u2014 emerge at the UAT level as confirmed product behavior.<\/p>\n
When they diverge \u2014 when UAT surfaces scenarios that have no corresponding structural representation, or when E2E tests cover journeys that no stakeholder actually cares about \u2014 both the tests and the architecture need reexamination.<\/p>\n
\n7. Diagnostic Signals<\/h2>\n
Testing difficulty is a signal. The nature of the difficulty points to the specific structural problem.<\/p>\n
Mock proliferation<\/strong> \u2014 a unit test mocking more than one or two dependencies is usually exercising something that spans too many concerns. The component should be decomposed, or its dependencies should be consolidated behind a single interface.<\/p>\nSlow unit tests<\/strong> \u2014 unit tests that require real I\/O (network, filesystem, database) are not unit tests. Something that should be an Accessor is embedded in an Engine or Flow. Extract it.<\/p>\nBrittle E2E tests<\/strong> \u2014 E2E tests that break for reasons unrelated to user-visible behavior are coupled to implementation detail. Either the test is asserting on internal component state (stop), or the flow being tested has no stable boundary (fix the architecture).<\/p>\nInverted pyramid<\/strong> \u2014 when the E2E suite is larger than the unit suite because unit tests cannot cover meaningful scenarios, the unit-testable tiers (Engines, Flows) contain less logic than they should. Business logic has migrated into Managers or Accessors.<\/p>\nUAT surprises<\/strong> \u2014 when UAT surfaces behaviors that no automated test predicted, either the core scenario set is incomplete or the structural model does not reflect how the product is actually used. Both are architectural discoveries, not testing failures.<\/p>\n
\n7A. Practitioner Observations<\/h2>\n
The following observations emerge from applying Boundary-Driven Testing across multiple systems of varying scale and domain. They are not prescriptive rules but recurring patterns \u2014 structural phenomena that practitioners encounter once the spiral is treated as an architectural map rather than a coverage checklist.<\/p>\n
The Test Migration Pattern<\/h3>\n
When architecture improves \u2014 when an Engine is extracted from a Manager, or an Accessor is separated from inline infrastructure calls \u2014 tests naturally migrate from integration scope to unit scope. Logic that previously could only be exercised through the Manager’s orchestration can now be tested directly against the extracted Engine. The test count at each spiral level is therefore a leading indicator of structural health. A system with a growing unit test count and a shrinking integration test count is decomposing correctly: logic is moving into testable tiers. A system where unit tests plateau while integration tests multiply is accumulating orchestration logic in the wrong places. Tracking this ratio over time reveals architectural trajectory more reliably than any static metric.<\/p>\n
The Mock Boundary Audit<\/h3>\n
Periodically reviewing where mocks are placed across the test suite reveals architectural drift before it becomes visible in production behavior. When a unit test that once required a single mock \u2014 the Accessor interface below the Engine \u2014 now requires three mocks, a boundary has leaked. The Engine has acquired a dependency it should not have, or a new collaborator has been introduced without going through the established interface. The audit is mechanical: list every mock in every unit test, group by component under test, and compare to the expected mock count for that component’s role. Engines should mock Accessors. Managers should mock Engines and Accessors. Utilities should mock nothing or at most one external sink. Deviations from this pattern are not judgment calls \u2014 they are structural findings that point to specific refactoring targets.<\/p>\n
The E2E Stability Correlation<\/h3>\n
E2E test stability correlates directly with Experience and Manager stability. When E2E tests become flaky \u2014 passing on one run, failing on the next, sensitive to timing or environment \u2014 the instability almost always traces to the orchestration tier rather than to infrastructure. The Manager or Experience is making decisions that depend on transient state, or it is sequencing operations in a way that is sensitive to timing that unit and integration tests never exercise. Stable Managers produce stable E2E tests. When E2E flakiness spikes, the first diagnostic step is not to add retries or increase timeouts \u2014 it is to examine what changed in the orchestration layer. The E2E suite is a Manager health monitor.<\/p>\n
The Coverage Paradox<\/h3>\n
Teams with high line coverage but poor boundary coverage consistently have worse defect rates than teams with moderate line coverage and strong boundary coverage. The explanation is structural: line coverage rewards exercising code paths, but many code paths are internal to a component and exercise only the easy branches. Boundary coverage \u2014 ensuring that every contract state a dependency can emit is handled by the caller \u2014 exercises the load-bearing logic: error handling, fallback paths, state transitions that only occur when a collaborator returns something unexpected. A team at 90% line coverage that never tests what happens when the Accessor returns a timeout has covered the lines but missed the boundary. A team at 65% line coverage that tests every Accessor contract state \u2014 success, not-found, timeout, malformed response \u2014 has covered less code but exercised far more of what matters. What matters is exercising contract states, not line counts.<\/p>\n
Accelerated Test Review<\/h3>\n
BDT makes test review faster and more consistent because reviewers have a structural question to ask rather than a subjective one. Instead of evaluating whether “enough” is tested or whether the test “looks right,” a reviewer checks that the test targets the correct spiral level for the component’s role. Is this an Engine? Then the test should be a unit test with mocked Accessors. Is this a Manager? Then the test should be an integration test exercising orchestration against mocked Engines. Is this a new E2E scenario? Then it should trace a complete user journey through the real stack. The review question shifts from “is this a good test?” to “is this test at the right level?” \u2014 a question with a definitive answer derived from the component’s structural position. Review time drops because the evaluation criteria are objective.<\/p>\n
Natural CI Pipeline Mapping<\/h3>\n
BDT interacts with CI pipelines by providing a principled mapping between spiral levels and pipeline stages. Unit tests run on every commit \u2014 they are fast, numerous, and catch logic regressions immediately. Integration tests run on pull request \u2014 they verify that the collaboration contracts between components are intact before code enters the shared branch. E2E tests run on merge to main \u2014 they confirm that the full system behaves correctly before deployment. System tests run in staging \u2014 they exercise non-functional qualities under realistic conditions. The spiral maps to the pipeline stages naturally because each stage has a different latency tolerance and a different confidence target. Teams that adopt BDT often find that their pipeline stage definitions, which previously felt arbitrary, now have a structural justification: each stage corresponds to a scope, and each scope corresponds to a tier.<\/p>\n
The Diagnostic Cascade<\/h3>\n
A failing E2E test should be reproducible as a failing integration test at one specific seam. If it is, the defect is localized: the collaboration between two components at that seam is broken, and the integration test pinpoints which contract state is mishandled. If it is not \u2014 if the E2E test fails but all integration tests pass \u2014 then one of two things is true. Either the E2E test is coupled to implementation detail that no integration test targets (the test is wrong), or the integration test suite is missing a contract state that the real system exercises (the suite is incomplete). The diagnostic cascade \u2014 E2E failure, then integration reproduction, then unit isolation \u2014 is how BDT converts a symptom into a structural finding. Each level of the cascade narrows the scope. A defect that survives to E2E without appearing at integration is always an architectural discovery about a missing seam or an untested contract state.<\/p>\n
The Refactor Safety Observation<\/h3>\n
When a system is structured according to VBD and tested according to BDT, internal refactoring within a component \u2014 changing how an Engine computes a result, optimizing an Accessor’s query strategy, restructuring a Manager’s orchestration sequence \u2014 is protected by the correct test level automatically. Refactoring an Engine’s internals is covered by its unit tests. Changing an Accessor’s implementation is covered by its unit tests against the mocked data source. Altering a Manager’s orchestration sequence is covered by its integration tests against mocked Engines. The key observation is that tests at the boundary do not care about internal restructuring \u2014 they care about the contract. This means that well-placed boundary tests provide refactoring confidence without requiring test updates for internal changes. When a refactor requires updating tests at multiple spiral levels, it is not a refactor \u2014 it is a contract change, and the test updates are the correct response.<\/p>\n
\n8. Conclusion<\/h2>\n
The spiral is not a burden. It is a reflection.<\/p>\n
A correctly decomposed system \u2014 one where Engines contain logic and Accessors contain I\/O and Managers contain orchestration and Utilities contain nothing domain-specific \u2014 produces a test suite that follows naturally from its structure. Unit tests are fast because Engines and Flows have no hidden dependencies. Integration tests are targeted because Accessors have narrow, stable interfaces. E2E tests are confident because Experiences and Managers represent complete, semantically meaningful journeys. UAT aligns because those journeys were designed to represent actual human purpose.<\/p>\n
The work of creating a good test suite is mostly the work of creating a good architecture. The spiral does not impose additional design constraints \u2014 it reads off the constraints already imposed by correct decomposition. When those constraints are satisfied, testing is an expression of the structure. When they are violated, testing is a fight against it.<\/p>\n
Boundary-Driven Testing names that relationship precisely. Boundaries determine test scope. Boundaries define mock points. Boundaries generate test profiles. Fix the boundaries and the spiral follows.<\/p>\n
\nAppendix A: Glossary<\/h2>\n
Architecturally Significant Boundary<\/strong> \u2014 A seam between components with distinct roles, such as Engine-Accessor or Flow-API Accessor. The correct and stable placement for test doubles.<\/p>\nBoundary-Driven Testing<\/strong> \u2014 A test strategy in which architectural boundaries between component roles determine test scope, mock placement, and assertion targets. Derived from VBD\/EBD decomposition rather than imposed as an external testing framework.<\/p>\nContract State<\/strong> \u2014 The set of possible return types a component can emit across its boundary, including success values, domain errors, and infrastructure failures. Tests must exercise every contract state to ensure the caller handles all outcomes.<\/p>\nControllability<\/strong> \u2014 The ability to place a component into a known state without invoking the full system. Required for isolation.<\/p>\nEnd-to-End Test<\/strong> \u2014 A test that exercises a full user-visible journey through the real stack with no mocks. In BDT, E2E tests target Manager and Experience components to verify that assembled paths produce correct outcomes against live dependencies.<\/p>\nIntegration Test<\/strong> \u2014 A test that verifies coordination between components at the Manager or Experience level, with dependencies mocked at the outer architectural boundary. In BDT, integration tests confirm that orchestration wiring matches the intended design.<\/p>\nInverted Pyramid<\/strong> \u2014 A test suite dominated by E2E tests because unit and integration tests cannot exercise meaningful behavior. A structural indicator of misplaced boundaries, not a testing indicator.<\/p>\nMock<\/strong> \u2014 A test double placed at an architecturally significant boundary to isolate the component under test from its dependencies. In BDT, mocks are positioned exclusively at role boundaries, not at arbitrary internal call sites.<\/p>\nMock Proliferation<\/strong> \u2014 A test requiring many simultaneous mocks. A signal that the component crosses too many boundaries or has absorbed too many responsibilities.<\/p>\nObservability<\/strong> \u2014 The ability to determine what a component did given controlled inputs. Required for meaningful assertion.<\/p>\nRefactoring Confidence<\/strong> \u2014 The assurance that internal changes to a component are safe so long as its boundary tests continue to pass. BDT provides this by anchoring tests to stable architectural seams rather than internal implementation details.<\/p>\nSeam<\/strong> \u2014 The point between two component roles where a mock is placed during testing. Seams exist at architecturally significant boundaries and represent the natural isolation surface for test doubles.<\/p>\nStructural Signal<\/strong> \u2014 Testing difficulty \u2014 such as excessive mocking, brittle assertions, or unclear scope \u2014 that reveals architectural misalignment rather than a testing tooling problem. BDT treats these signals as prompts to fix boundaries, not tests.<\/p>\nSystem Test<\/strong> \u2014 A test that targets non-functional qualities such as resilience, performance, and deployment correctness. System tests use failure injection, load generation, and configuration variation against the full assembled system.<\/p>\nTest Profile<\/strong> \u2014 The characteristic test shape of a component role, specifying what is tested, what is mocked, and what is asserted. Each VBD\/EBD role (Engine, Accessor, Manager, Utility, etc.) has a distinct test profile determined by its boundary relationships.<\/p>\nTest Spiral<\/strong> \u2014 A progression of test scope from unit through integration, end-to-end, system, and user acceptance. Each level corresponds to a level of architectural scope, and the spiral shape emerges naturally from correct boundary placement.<\/p>\nUnit Test<\/strong> \u2014 A test that exercises the internal logic of a single component \u2014 typically an Engine, Flow, or Utility \u2014 with all dependencies mocked at their architectural boundaries. In BDT, unit tests verify logic correctness and full contract-state coverage.<\/p>\nUser Acceptance Test<\/strong> \u2014 A test performed by real users against the live system to verify that core journeys fulfill business intent. UATs use no mocks and validate that the system delivers actual value, not just technical correctness.<\/p>\n
\nAppendix B: BDT at a Glance<\/h2>\n
\n\n\n| Spiral Level<\/th>\n | Primary Structural Target<\/th>\n | Mock Strategy<\/th>\n | Assertion Scope<\/th>\n<\/tr>\n<\/thead>\n |
\n\n| Unit<\/td>\n | Engine \u00b7 Flow \u00b7 Utility \u00b7 Interaction<\/td>\n | Mock all dependencies through their contracts<\/td>\n | Logic correctness; all contract states handled<\/td>\n<\/tr>\n |
\n| Integration<\/td>\n | Manager \u00b7 Experience coordination<\/td>\n | Mock at outer boundary; dependencies return controlled contract states<\/td>\n | Collaboration wiring; orchestration matches design<\/td>\n<\/tr>\n |
\n| End-to-End<\/td>\n | Manager \u00b7 Experience<\/td>\n | No mocks; full stack; real external systems<\/td>\n | User-visible outcome; journey completion<\/td>\n<\/tr>\n |
\n| System<\/td>\n | Full system<\/td>\n | Failure injection; load; configuration variation<\/td>\n | Non-functional qualities; resilience; deployment correctness<\/td>\n<\/tr>\n |
\n| UAT<\/td>\n | Core use case \/ Core user journey<\/td>\n | None (real users)<\/td>\n | Business intent fulfilled<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
\nAppendix C: Case Study \u2014 E-Commerce Order Processing<\/h2>\nThis appendix presents a fictional but structurally realistic example of BDT applied to an e-commerce order processing system. The architecture follows VBD role assignments. The test suite follows the spiral. The example demonstrates how boundary placement determines test scope, mock strategy, and maintenance cost \u2014 and how adding a new capability requires minimal test changes when the boundaries are correct.<\/p>\n C.1 System Architecture<\/h3>\nThe order processing system is decomposed into the following components:<\/p>\n \n- OrderManager<\/strong> \u2014 orchestrates the order lifecycle: validates, prices, checks inventory, processes payment, persists, and notifies. Contains no business logic. Sequences Engine calls and handles cross-cutting routing.<\/li>\n
- ValidationEngine<\/strong> \u2014 applies order validation rules: required fields, item availability constraints, customer eligibility, promotion expiration.<\/li>\n
- PricingEngine<\/strong> \u2014 calculates order totals: base pricing, volume discounts, promotional codes, tax computation, currency handling.<\/li>\n
- InventoryEngine<\/strong> \u2014 determines fulfillment feasibility: stock checks, reservation logic, partial fulfillment decisions, backorder policy.<\/li>\n
- OrderRepositoryAccessor<\/strong> \u2014 translates domain order objects to and from the persistent store. Handles serialization, query construction, and connection management.<\/li>\n
- PaymentGatewayAccessor<\/strong> \u2014 translates payment requests into gateway-specific API calls. Handles authentication, request formatting, response parsing, and error translation.<\/li>\n
- NotificationAccessor<\/strong> \u2014 translates notification requests into delivery channel calls (email, SMS, push). Handles template selection and delivery confirmation.<\/li>\n
- LoggingUtility<\/strong> \u2014 structured log emission. Pure sink: accepts log entries, formats them, writes to the configured transport. No domain awareness.<\/li>\n<\/ul>\n
%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#e0e7ff', 'primaryTextColor': '#1e293b', 'primaryBorderColor': '#4338ca', 'lineColor': '#4338ca', 'background': '#ffffff', 'mainBkg': '#e0e7ff', 'nodeBorder': '#4338ca', 'clusterBkg': '#f5f3ff', 'edgeLabelBackground': '#ffffff'}}}%%\n\nflowchart TD\n subgraph manager[\"Manager Tier\"]\n OM[\"OrderManager\"]\n end\n\n subgraph engines[\"Engine Tier\"]\n VE[\"ValidationEngine\"]\n PE[\"PricingEngine\"]\n IE[\"InventoryEngine\"]\n end\n\n subgraph accessors[\"Accessor Tier\"]\n ORA[\"OrderRepositoryAccessor\"]\n PGA[\"PaymentGatewayAccessor\"]\n NA[\"NotificationAccessor\"]\n end\n\n subgraph utilities[\"Utility Tier\"]\n LU[\"LoggingUtility\"]\n end\n\n OM --> VE\n OM --> PE\n OM --> IE\n OM --> ORA\n OM --> PGA\n OM --> NA\n VE --> ORA\n PE --> ORA\n IE --> ORA\n OM --> LU\n\n<\/div><\/p>\n C.2 Unit Test Suite<\/h3>\nEach Engine is tested in isolation. Accessors below each Engine are mocked. The tests exercise every branch of the Engine’s logic by controlling the inputs and the mock responses.<\/p>\n ValidationEngine Unit Tests<\/h4>\n\n\n\n| Test Scenario<\/th>\n | Input<\/th>\n | Mock Setup<\/th>\n | Expected Result<\/th>\n<\/tr>\n<\/thead>\n | \n\n| Missing required field (customer email)<\/td>\n | Order with null email<\/td>\n | None needed<\/td>\n | ValidationFailure("missing_required_field", "email")<\/code><\/td>\n<\/tr>\n\n| Empty line items<\/td>\n | Order with zero items<\/td>\n | None needed<\/td>\n | ValidationFailure("empty_order", null)<\/code><\/td>\n<\/tr>\n\n| Expired promotional code<\/td>\n | Order with promo code “SUMMER2025”<\/td>\n | OrderRepositoryAccessor returns promo with expires: 2025-09-01<\/code><\/td>\nValidationFailure("expired_promotion", "SUMMER2025")<\/code><\/td>\n<\/tr>\n\n| Out-of-stock item (validation-level check)<\/td>\n | Order with item SKU-9912<\/td>\n | OrderRepositoryAccessor returns stock_count: 0<\/code> for SKU-9912<\/td>\nValidationFailure("item_unavailable", "SKU-9912")<\/code><\/td>\n<\/tr>\n\n| Customer account suspended<\/td>\n | Order with customer ID 4401<\/td>\n | OrderRepositoryAccessor returns customer with status: suspended<\/code><\/td>\nValidationFailure("customer_ineligible", "account_suspended")<\/code><\/td>\n<\/tr>\n\n| Valid order, all checks pass<\/td>\n | Complete order, all fields present<\/td>\n | OrderRepositoryAccessor returns valid promo, positive stock, active customer<\/td>\n | ValidationPass(order)<\/code><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\nPricingEngine Unit Tests<\/h4>\n\n\n\n| Test Scenario<\/th>\n | Input<\/th>\n | Mock Setup<\/th>\n | Expected Result<\/th>\n<\/tr>\n<\/thead>\n | \n\n| Volume discount threshold (100+ units)<\/td>\n | Order with 150 units of SKU-1001<\/td>\n | OrderRepositoryAccessor returns tier pricing: 100+ at 15% discount<\/td>\n | PricedOrder(discount_applied: "volume_15pct")<\/code><\/td>\n<\/tr>\n\n| Promotional code (percentage)<\/td>\n | Order with promo “SAVE20”<\/td>\n | OrderRepositoryAccessor returns promo: 20% off, no exclusions<\/td>\n | PricedOrder(promo_applied: "SAVE20", discount: 20%)<\/code><\/td>\n<\/tr>\n\n| Promotional code with exclusion<\/td>\n | Order with promo “SAVE20”, item in exclusion list<\/td>\n | OrderRepositoryAccessor returns promo with exclusion list containing item SKU<\/td>\n | PricedOrder(promo_applied: null, exclusion_reason: "item_excluded")<\/code><\/td>\n<\/tr>\n\n| Tax calculation (multi-jurisdiction)<\/td>\n | Order shipping to CA<\/td>\n | OrderRepositoryAccessor returns CA tax rate 8.25%<\/td>\n | PricedOrder(tax_rate: 8.25%, tax_amount: computed)<\/code><\/td>\n<\/tr>\n\n| Combined volume + promo (stacking rules)<\/td>\n | 150 units with promo “SAVE20”<\/td>\n | OrderRepositoryAccessor returns stacking policy: “best_single”<\/td>\n | PricedOrder(discount_applied: "volume_15pct", stacking: "best_single_applied")<\/code><\/td>\n<\/tr>\n\n| Zero-cost order (full discount)<\/td>\n | Order fully covered by store credit<\/td>\n | None needed<\/td>\n | PricedOrder(total: 0.00, payment_required: false)<\/code><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\nInventoryEngine Unit Tests<\/h4>\n\n\n\n| Test Scenario<\/th>\n | Input<\/th>\n | Mock Setup<\/th>\n | Expected Result<\/th>\n<\/tr>\n<\/thead>\n | \n\n| Full stock available<\/td>\n | Order for 10 units, 50 in stock<\/td>\n | OrderRepositoryAccessor returns available: 50<\/code><\/td>\nInventoryReserved(full, reservation_id)<\/code><\/td>\n<\/tr>\n\n| Partial stock, backorder allowed<\/td>\n | Order for 10 units, 3 in stock<\/td>\n | OrderRepositoryAccessor returns available: 3<\/code>, backorder policy: allowed<\/td>\nInventoryPartial(available: 3, backordered: 7, reservation_id)<\/code><\/td>\n<\/tr>\n\n| Partial stock, backorder disallowed<\/td>\n | Order for 10 units, 3 in stock<\/td>\n | OrderRepositoryAccessor returns available: 3<\/code>, backorder policy: disallowed<\/td>\nInventoryInsufficient(available: 3, required: 10)<\/code><\/td>\n<\/tr>\n\n| Multi-item reservation (atomic)<\/td>\n | Order for 3 SKUs<\/td>\n | OrderRepositoryAccessor returns stock for all 3<\/td>\n | InventoryReserved(full, reservation_ids: [r1, r2, r3])<\/code><\/td>\n<\/tr>\n\n| Reservation timeout recovery<\/td>\n | Order for 10 units<\/td>\n | OrderRepositoryAccessor returns reservation then timeout on confirm<\/td>\n | InventoryError("reservation_timeout", reservation_id)<\/code><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\nMock placement for all Engine unit tests:<\/strong><\/p>\n%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#e0e7ff', 'primaryTextColor': '#1e293b', 'primaryBorderColor': '#4338ca', 'lineColor': '#4338ca', 'background': '#ffffff', 'mainBkg': '#e0e7ff', 'nodeBorder': '#4338ca', 'clusterBkg': '#f5f3ff', 'edgeLabelBackground': '#ffffff'}}}%%\n\nflowchart TD\n subgraph unit_scope[\"Unit Test Scope\"]\n VE[\"ValidationEngine (real)\"]\n PE[\"PricingEngine (real)\"]\n IE[\"InventoryEngine (real)\"]\n end\n\n subgraph mocked[\"Mocked at Boundary\"]\n ORA[\"OrderRepositoryAccessor (mock)\"]\n end\n\n VE -->|\"reads\"| ORA\n PE -->|\"reads\"| ORA\n IE -->|\"reads\/writes\"| ORA\n\n<\/div><\/p>\n C.3 Integration Test Suite<\/h3>\nIntegration tests exercise the seams between tiers. Each seam is tested with the caller real and the callee mocked, returning controlled contract states. The question is not whether the callee works \u2014 that is answered by its unit tests \u2014 but whether the caller handles every state the callee can emit.<\/p>\n Seam: OrderManager to ValidationEngine<\/h4>\n\n\n\n| Test Scenario<\/th>\n | Mock Response from ValidationEngine<\/th>\n | Expected Manager Behavior<\/th>\n<\/tr>\n<\/thead>\n | \n\n| Validation passes<\/td>\n | ValidationPass(order)<\/code><\/td>\n| Manager proceeds to PricingEngine<\/td>\n<\/tr>\n | \n| Validation fails (missing field)<\/td>\n | ValidationFailure("missing_required_field", "email")<\/code><\/td>\n| Manager returns rejection, no downstream calls made<\/td>\n<\/tr>\n | \n| Validation fails mid-order (concurrent modification)<\/td>\n | ValidationFailure("order_modified_concurrently", order_id)<\/code><\/td>\n| Manager returns conflict error, logs warning, no payment attempted<\/td>\n<\/tr>\n | \n| ValidationEngine throws unexpected error<\/td>\n | RuntimeException("database_unavailable")<\/code><\/td>\nManager returns system error, logs critical, no downstream calls<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\nSeam: OrderManager to PricingEngine<\/h4>\n\n\n\n| Test Scenario<\/th>\n | Mock Response from PricingEngine<\/th>\n | Expected Manager Behavior<\/th>\n<\/tr>\n<\/thead>\n | \n\n| Pricing succeeds<\/td>\n | PricedOrder(total: 142.50)<\/code><\/td>\n| Manager proceeds to InventoryEngine<\/td>\n<\/tr>\n | \n| Pricing returns zero total<\/td>\n | PricedOrder(total: 0.00, payment_required: false)<\/code><\/td>\n| Manager skips PaymentGatewayAccessor, proceeds to persist<\/td>\n<\/tr>\n | \n| PricingEngine returns error<\/td>\n | PricingError("tax_service_unavailable")<\/code><\/td>\nManager returns pricing failure, no inventory reservation attempted<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\nSeam: OrderManager to InventoryEngine<\/h4>\n\n\n\n| Test Scenario<\/th>\n | Mock Response from InventoryEngine<\/th>\n | Expected Manager Behavior<\/th>\n<\/tr>\n<\/thead>\n | \n\n| Full inventory reserved<\/td>\n | InventoryReserved(full, reservation_id)<\/code><\/td>\n| Manager proceeds to payment<\/td>\n<\/tr>\n | \n| Partial inventory, backorder<\/td>\n | InventoryPartial(available: 3, backordered: 7)<\/code><\/td>\n| Manager proceeds to payment with adjusted total, notifies customer of partial fulfillment<\/td>\n<\/tr>\n | \n| Inventory insufficient<\/td>\n | InventoryInsufficient(available: 3, required: 10)<\/code><\/td>\nManager returns inventory failure, no payment attempted<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\nSeam: OrderManager to PaymentGatewayAccessor<\/h4>\n\n\n\n| Test Scenario<\/th>\n | Mock Response from PaymentGatewayAccessor<\/th>\n | Expected Manager Behavior<\/th>\n<\/tr>\n<\/thead>\n | \n\n| Payment authorized<\/td>\n | PaymentAuthorized(transaction_id)<\/code><\/td>\n| Manager persists order, sends confirmation notification<\/td>\n<\/tr>\n | \n | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |