bcquality/custom/knowledge/testing/test-one-when-per-test.md

bc-version	domain	keywords	technologies	countries	application-area
all	testing	test when scenario single-action bdd atdd given-when-then	al	w1	all

Description

Each test procedure must contain exactly one [WHEN] block — one action that triggers the behaviour under test. A test with multiple WHENs ("do A, then do B, then check C") is really two or more tests in disguise. Split them.

This constraint serves two purposes:

1. Failure isolation — when the test fails you know which action caused it.
2. Readable specification — each test reads as a single, falsifiable claim about the system's behaviour.

A scenario that genuinely requires a precondition action (e.g. "post an order so that a ledger entry exists") belongs in [GIVEN]. Only the action being asserted belongs in [WHEN].

Anti Pattern

// WRONG: two actions in one test
[Test]
procedure GetPrice_ThenGetDiscount_ReturnsCorrectValues()
var
    UnitPrice, LineDiscPct: Decimal;
begin
    // [GIVEN] ...
    // [WHEN] first action
    FindPriceMgt.GetSalesPrice(CustomerNo, ItemNo, '', UnitPrice, LineDiscPct);
    // [WHEN] second action — this is a second test in disguise
    FindPriceMgt.GetSalesPriceTiers(CustomerNo, ItemNo, '', TempBuffer);
    // [THEN] asserting two unrelated things
    Assert.AreEqual(100, UnitPrice, '');
    Assert.IsFalse(TempBuffer.IsEmpty(), '');
end;

Best Practice

// CORRECT: split into two focused tests

[Test]
procedure GetPrice_CustomerPrice_ReturnsCorrectUnitPrice()
var
    UnitPrice, LineDiscPct: Decimal;
begin
    // [GIVEN] a customer with a price list line at 100
    WarecoLib.GivenCustomerWithPrice(Customer, Item, '', 100);
    // [WHEN]
    FindPriceMgt.GetSalesPrice(Customer."No.", Item."No.", '', UnitPrice, LineDiscPct);
    // [THEN]
    Assert.AreEqual(100, UnitPrice, 'Unit price must match price list');
end;

[Test]
procedure GetPriceTiers_CustomerTier_ReturnsOneTierLine()
var
    TempBuffer: Record "Find Price Tier Buffer" temporary;
begin
    // [GIVEN] a customer with a tier price at min qty 10
    WarecoLib.GivenCustomerWithTierPrice(Customer, Item, '', 10, 90);
    // [WHEN]
    FindPriceMgt.GetSalesPriceTiers(Customer."No.", Item."No.", '', TempBuffer);
    // [THEN]
    Assert.AreEqual(1, TempBuffer.Count(), 'Exactly one tier line expected');
end;

Flow tests — the deliberate exception

A flow test verifies the accumulated outcome of a multi-round business flow (partial receipt then invoicing, multiple posting rounds against one document). The sequence IS the scenario — splitting it loses the interaction under test. Multiple [WHEN] blocks are permitted when ALL of these hold:

1. The name declares the flow (SVPartialFlowTests, ReceiveThenInvoice_QuantitiesAreCorrect).
2. Each [WHEN] is labelled as a round of ONE scenario ("Runde 1: kun modtagelse"), not as an unrelated action.
3. The [THEN] asserts the accumulated end-state. If the assertions decompose cleanly per action, it is two tests in disguise: split.

Unit-level tests keep the strict one-WHEN rule without exception. (Edison eval 2026-07-02, Jernpladsen @ b7656b1: five deliberate round-labelled flow procedures in SVPartialFlowTests — the rule previously gave no verdict.)

Defect-then-fix regression tests — a second, narrower exception

A test that reproduces a specific stale/broken state and then verifies a subsequent action corrects it (RecalcRestoresStaleDiscountAfterPick: pick creates the stale state, recalc is the fix under test) is not the same shape as an unrelated-action test, even though its [THEN] assertions decompose cleanly per step — decomposing cleanly is expected here, not a sign of two unrelated tests. The three flow-test conditions above are the wrong fit for this case: the name doesn't need to declare a multi-round "flow," and there is no natural "Runde 1/2" framing for "create the broken state, then fix it." This shape is permitted when:

1. The second [WHEN] cannot be meaningfully tested without the first — the fix being verified only has an effect on the specific stale state the first action produced, so splitting would require re-running the first action inside a second test's [GIVEN] anyway, testing nothing new.
2. The procedure name communicates the before/after relationship (a defect symptom and its correction), even without the word "flow."

Applying flow-test criterion 3 ("assertions decompose cleanly → split") to this shape would have been a false positive (Edison eval 2026-08-13, Wareco @ a2fc8ff8, SalesOrderAmountAfterPickTest.RecalcRestoresStaleDiscountAfterPick) — clean decomposition is exactly what a defect-then-fix test's assertions are supposed to do at each step, not evidence the steps belong in separate tests.

Naming implication

The procedure name should make the single WHEN self-evident. A name with "And" or "Then" in the middle is a strong signal to split:

• GetPrice_AndDiscount_ReturnsValues → split
• GetPrice_CustomerPrice_ReturnsUnitPrice → good
• ReceiveThenInvoice_QuantitiesAreCorrect → legitimate flow test IF the flow-test conditions above are met