Microsoft/bcquality
1
0
Fork 0
mirror of https://github.com/microsoft/BCQuality.git synced 2026-10-05 14:46:55 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions 4
bcquality/custom/knowledge/testing/test-one-when-per-test.md
Michael Dieringer dd5637b1db Custom-laget bestaar nu begge CI-checks: 72 validator-fejl -> 0 
Normalisering af alle 39 custom knowledge-filer til READ-kontraktens
skema (validate_frontmatter.py + Test-KnowledgeIndex.ps1 begge groenne):

- R01/R02: 28 filer manglede frontmatter eller brugte aeldre skemaer
  (title/category/severity/rule-id m.fl.) - alle har nu praecis de 6
  kraevede noegler; keywords haandskrevet pr. fil da de driver
  worklist-selektionen i INDEX/knowledge-index
- R09: manglende Description-sektion - regel-agtige foersteoverskrifter
  (Core Rule/Rule/Regel/Core Principle) omdoebt, eller sektion indsat
  efter titlen hvor intro-tekst fandtes
- R10: fenced code blocks konverteret til 4-space indrykkede blokke
  i alle filer (indhold uaendret)
- R11: 4 filer over 100 linjer fortaettet redaktionelt uden semantisk
  tab (ai-eval-scores 143->100, git-lifecycle 121->97,
  permission-sets 113->99, test-feature-scenario-tags 105->91)
- R05: AL0197->al0197, add_repo->add-repo; keyword-lister trimmet
  til maks 10

Ingen regler er fjernet eller aendret i betydning - kun form.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-01 23:47:31 +02:00

2.7 KiB
Raw Blame History

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;

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