Knowing Which Scenarios a Feature Requires

An active customer places an order. We need to know whether the system used the catalog prices, recorded every line, notified fulfillment, and prepared the correct confirmation for that customer. A green test gives us useful confidence only if its scenario and assertions cover what the feature requires.

About the examples: Meridian Ordering is a private training reference project. The inline listings illustrate the techniques; the full C# and Python repositories are not currently public.

Before that test is written, the team establishes the business requirements, acceptance criteria, functional requirements, and non-functional requirements. It then verifies that the test scenarios and expectations correctly cover them. When the required suite is green under those conditions, the team has confidence to go to production.

This article uses Meridian’s Place Order feature to show how to make those connections. An obligation map records each requirement, the scenario that exercises it, where the test gets its actual results, and what it compares.

Begin with the established feature requirements

Place Order specifies who may order, what a line contains, where prices come from, how totals are calculated, and which orders require review. It defines what an accepted order records and communicates. It also defines rejection, idempotency, partial failure, and the outstanding work after a downstream action fails.

Its acceptance criteria make these rules concrete. AC-01 describes an active customer ordering three Widgets and two Gadgets. The stated catalog prices yield a total of $558.97. The order is recorded, fulfillment is notified, a confirmation email is sent, and the caller receives the accepted outcome.

The specification also names technical and non-functional obligations. Transaction integrity, concurrent duplicate handling, canonical SKU identity, bounded retry, and safe failure diagnostics need verification. Several arise from the chosen implementation, so developers must identify and explain them.

The source uses BR, AC, TR, and NFR identifiers. Its functional obligations appear in the business rules, acceptance criteria, and technical requirements; it does not introduce a separate FR numbering scheme. We preserve those identifiers when mapping the supplied requirements.

The approved requirements supply the expected behavior. The current implementation shows how that behavior is implemented. A test expectation needs to remain anchored to the requirement when the implementation changes.

Break each outcome into verifiable obligations

Take the accepted-order criterion. Saying that the order was placed leaves too much unspecified for a useful test. The criterion tells us what must be correct:

Some rows contain many assertions. An order line has several required values. A notification must propagate those values correctly. Treating an entire effect as one obligation makes the test readable; it does not reduce the comparison to a presence check.

This is why assertion depth belongs in a completeness review. A test can exercise the right scenario and still leave a required field unverified.

Record the connection from requirement to assertion

An obligation map makes the review concrete. For each obligation, record:

1. The source requirement and the rule it expresses.
2. The scenario, including any same-rule data rows.
3. The conditions that make the arrangement valid for that scenario.
4. The independently established expected outcome.
5. The observation used to gather what actually happened.
6. The assertion that compares the required outcome.

For AC-01’s order total, the map connects BR-5’s formula to the catalog products read during Arrange. The test calculates each expected line total as quantity times unit price and adds the results. It observes the caller’s result, reads the stored order, and receives the fulfillment payload. Its asserters compare the total in each required representation.

Here is the calculation used in the successful-order test. The products have already been read from the database during Arrange:

/// Arrange: apply BR-5 to the prices read from the product catalog.
decimal expectedFirstLineTotal = firstCatalogProduct.UnitPrice * firstLineQuantity;
decimal expectedSecondLineTotal = secondCatalogProduct.UnitPrice * secondLineQuantity;

The test adds those amounts when building the expected order. It gathers the actual stored values only after invoking the operation:

/// Assert: read what the operation stored and published.
var actualRecordedOrder = DataManagerForTest.GetRecordedOrder(orderPlacementRequest.OrderReference);
var actualFulfillmentNotificationPayload = await BrokerSubscriptions.ReceiveMessageForOrderAsync(
    subscriberFulfillmentNotifications, orderPlacementRequest.OrderReference);
var actualExtraFulfillmentNotificationPayload = await BrokerSubscriptions.TryReceiveMessageForOrderAsync(
    subscriberFulfillmentNotifications, orderPlacementRequest.OrderReference);
var actualPlacementWindowEndUtc = DateTime.UtcNow;

The order total in the return value, database record, and fulfillment message must each match the total established during Arrange. Reading actual values from the system is necessary: comparing two expected models would tell us nothing about what the operation did. The full test and aggregate asserter show those comparisons together.

Here is the stored-total comparison inside AsserterOrderStore. It compares the expected amount with the value read from the order record and adds a useful failure message when they differ:

/// Assert: compare the expected total with the actual database value.
if (actualRecordedOrder.OrderTotal != expectedOrderTotal)
{
    assertionFailures.Add(
        $"Expected Order Total: {expectedOrderTotal}\n" +
        $"Actual Order Total:   {actualRecordedOrder.OrderTotal}\n" +
        $"Order Reference:      {orderReference}\n" +
        $"\nBusiness Rule Violated:\n  BR-5: the order total is the sum of quantity times catalog unit price across all lines.\n");
}

This excerpt comes from the helper’s comparison method. The complete asserter also checks the customer, status, placement time, and complete order lines. A map entry should identify those comparisons as well as the scenario name.

For the confirmation email, BR-8 supplies the destination and content obligations. The test uses the customer’s address on file, captures the gateway’s outbound request, and compares its fields. The production composer used to build expected content has independent class tests that establish its output. Reusing that composer carries a verification responsibility of its own.

Meridian intentionally captures the request without a separate running email service. With a stable real provider, the production arrangement can preserve the original request, redirect delivery to a controlled test address, and read the message from that inbox. The map then records two observations: the original customer recipient and content, and the delivered message at the test destination. The email explanation shows why both matter.

The Place Order obligation map records the feature-level requirements and the detailed AC-01 connections. The complete walkthrough shows the test and the mechanisms behind those connections. The Customer Registration map applies the same review to its 25 BR/AC identifiers and records the expected observations for its no-return operation.

Review the arrangement as carefully as the expectation

A test named for a particular scenario has to create its defining conditions. Consider the review threshold. The business rule releases an order whose total is $10,000.00 or less and holds a higher total for review.

The exact-threshold scenario uses four units of the Calibration Rig. The test reads that product’s current catalog price and checks that the arranged total is exactly $10,000.00 before calling the service. If the seed price changes, the guard reports that the catalog no longer supports the named scenario.

Here is the arrangement guard from the exact-threshold scenario. These selected statements show the price read and premise check; the source method also builds the request and expected order:

/// Arrange: establish that this scenario lands exactly on the threshold.
var catalogProduct = DataManagerForTest.GetCatalogProduct(DataGenerators.CalibrationRigSku);
int atThresholdQuantity = 4;
decimal expectedOrderTotal = catalogProduct.UnitPrice * atThresholdQuantity;
Assert.True(
    expectedOrderTotal == AcceptanceTestConstants.HeldForReviewThresholdTotal,
    $"AC-09 arrange guard: {atThresholdQuantity} x {catalogProduct.Sku} totals {expectedOrderTotal}, not exactly " +
    $"{AcceptanceTestConstants.HeldForReviewThresholdTotal} - the seeded catalog no longer supports this boundary scenario");

Although this uses Assert.True, it belongs to Arrange: it checks that the inputs create the promised scenario. After Act, the outcome assertions check whether the system released that order and produced the required records and communications.

Without the guard, the test could continue passing while exercising a different total. Its name and requirement reference would then describe behavior it no longer demonstrates.

The ordinary accepted-order scenario uses constrained random selection. Its prices are capped so that any permitted draw remains within the Placed threshold. Randomness varies inputs inside the named scenario. The defining business conditions remain deliberate.

Apply the same review to inactive customers, unknown products, conflicting resubmissions, and transaction failures. The setup must establish the condition the test claims to verify.

Include refusals, absence, and partial failure

An invalid request must return the specific reason for rejection. It must also leave no order or outbound work. Both parts belong to the outcome.

The rejected-path scenarios cover unknown and inactive customers, missing lines, invalid quantities, unknown products, and duplicate products. Quantity rows of 0 and 101 demonstrate rejection outside the allowed range. Rows of 1 and 100 demonstrate the inclusive boundaries. Those are separate claims about the rule.

A failure before recording completes differs from a failed action afterward. Meridian’s rollback scenario delays an order-line insertion in a private database until the SQL command times out. It then checks the affected table counts and outbound absence. The arrangement requires the actual transaction to begin, so the test verifies rollback after work has started.

After commit, the business requires the accepted order to stand. A failed fulfillment action must remain owed, while email proceeds when possible. A failed email must remain owed after fulfillment succeeds. A failure to record completion must preserve the accepted order and report the resulting uncertainty.

Those requirements explain the business-required catches in the production path. The tests verify their intended outcomes, including durable action state and diagnostic evidence. Catching a defined operational failure to implement that policy belongs to the feature’s behavior.

Review technical and non-functional requirements too

Business acceptance examples do not enumerate everything developers need to verify. A unique order-reference constraint must arbitrate concurrent requests. A malformed database response must be translated into a meaningful failure. An email retry must honor the required delay and stop after the bounded policy. Failure diagnostics must remain safe and bounded even when a provider returns an oversized body or the connection drops while it is read.

These obligations come from the feature’s technical and non-functional requirements. They join the same maintained suite, with the same requirement for correct arrangements, expectations, and observable evidence.

Some requirements concern implementation structure directly, such as using one stored procedure for the ordinary placement transaction. Source and code review establish those structural facts. The functional scenarios establish the resulting behavior. Record which evidence answers which obligation rather than assigning proof to a test that does not contain it.

Establish who reviews what

The product team confirms the business requirements and the scenarios that express them. Developers confirm technical obligations and the arrangements and assertions needed to verify them. Review includes the expected values and required absence, because either can be wrong even when a test passes.

The executable scenarios can be presented in a form stakeholders can review. That presentation needs to remain tied to the source scenarios. If the team uses formal sign-off, the reviewed version, ownership, and triggers for renewed approval should be explicit.

When the business intentionally changes a rule, the affected scenarios and expectations change with it. When an implementation change breaks an unchanged rule, the existing scenario should expose the regression.

Preserve what the team learns

A completeness review addresses the obligations established for the feature. The team will also learn from later review, QA, exploratory work, generators, mutation analysis, and incidents. Each discovered behavioral obligation needs a permanent place in the maintained suite.

Sometimes that means adding a named scenario. Sometimes it means another data row for the same rule or an assertion for a previously unchecked field. A mistaken expectation requires correction against the requirement.

The release condition remains precise: the requirements have been established, the scenarios and expectations correctly cover them, and the assembled system passes those checks. That is how the team gives meaning to a green result and earns confidence to go to production.

Place Order obligation map

This is the supporting requirement-to-evidence map for the scenario-completeness article and the order walkthrough. It uses ORD-001 at Meridian revision 501e097f66b884615f517c5252d1ab719709f421.

The supplied specification identifies business requirements, acceptance criteria, technical requirements, and non-functional requirements. Functional obligations are expressed within those sections. Their established correctness and the correctness of the scenarios and expectations are prerequisites for release confidence. This source map records where the evidence resides; its rows do not constitute a separate sign-off on every requirement.

Feature-wide requirement destinations

The evidence column distinguishes asserted outcomes, production structural review, and reviewed provider contracts. A test reference cannot stand in for an assertion or certify an architectural property it does not observe.

AC-01: detailed obligation map

The scenario reads two distinct eligible catalog products and uses quantities of 3 and 2. It caps eligible prices to preserve the Placed outcome and derives the expected total using BR-5. It submits swapped-case SKUs and expects canonical identity in recorded and outbound values.

The composite asserter gathers the comparison reports for five obligation groups: caller, store, fulfillment content, extra-message absence, and email. It reports all available discrepancies together. Those groups contain the individual field checks recorded above.

Reading the evidence together

Use the complete walkthrough for the full test, composite method, supporting techniques, and recorded selected-run results. Use the feature specification for the intended outcomes and production source for structural facts. A passing selected run records execution in that environment. Correct coverage and correct expectations are established through the feature’s requirements and scenario review.

Customer Registration obligation map

This map complements the Place Order map. Its source is the CUS-001 feature specification. The specification contains ten BR identifiers and fifteen AC identifiers. It does not supply separate FR, TR, or NFR numbering. Functional rules and technical verification still need review; do not invent identifiers to make the map appear complete.

The executable evidence comes from the complete registration expected paths, refusals, edge cases, failures, and rollback.

The success asserter compares supplied values with an independent database read, counts customers for the reserved email, and verifies system-added identity and bounded registration time. The refusal scenarios compare specific exceptions, problem information, and unchanged customer counts or records as appropriate. This is a source-based review map, not a certification that every possible input has been executed.

Follow no-return success into its actual state

The accepted-registration comparison follows the recorded values all the way into the stored customer:

Its helper compares email, names, company, status, optional fields, and opt-in. The aggregate then checks a nonblank customer identifier and registration time inside the operation window with the defined clock-skew allowance. Those are the actual identity/time checks; the map does not claim a stronger identifier format assertion than the code contains.

The specification’s examples illustrate rules. Tests use fresh reserved email identities and constrained arrangements rather than sharing those example customers across runs. Existing-customer scenarios explicitly insert the customer whose identity and privacy they need to preserve.

Technical limits introduced by the build, such as storage-driven lengths, concurrent uniqueness, or provider translation, need their own scenarios and review. A missing technical requirement cannot be repaired by pretending it was part of a business maximum that the source explicitly does not define.

Previous article | Series contents | Next article