mirror of
https://github.com/microsoft/BCQuality.git
synced 2026-10-06 23:26:55 +01:00
Merge pull request #51 from Curabis/knowledge/edison-sharpening-round-1
Edison sharpening runde 1: singleton-undtagelse + flow-test-grænse (Type A)
This commit is contained in:
commit
b2574aa117
2 changed files with 27 additions and 1 deletions
|
|
@ -18,10 +18,16 @@ In CURABIS codebases, pages serve exclusively as presentation layers. All busine
|
||||||
|
|
||||||
## Permitted Exceptions
|
## Permitted Exceptions
|
||||||
|
|
||||||
Two specific scenarios allow deviation from this rule:
|
Three specific scenarios allow deviation from this rule:
|
||||||
|
|
||||||
1. **Setup Pages**: May directly read and write their own setup records
|
1. **Setup Pages**: May directly read and write their own setup records
|
||||||
2. **Conversion Pages**: The designated "Run Conversion" page may invoke the conversion codeunit directly
|
2. **Conversion Pages**: The designated "Run Conversion" page may invoke the conversion codeunit directly
|
||||||
|
3. **Cue/Activities Pages**: The standard singleton-initialization idiom in
|
||||||
|
`OnOpenPage` — `if not Rec.Get() then begin Rec.Init(); Rec.Insert(); end` —
|
||||||
|
is permitted. It bootstraps the page's own presentation-state record and is
|
||||||
|
the same pattern Microsoft uses on every base-app cue page; it is not
|
||||||
|
business logic. (Edison eval 2026-07-02, Jernpladsen @ b7656b1: the rule
|
||||||
|
flagged this idiom on an Activities page; adjudicated false positive.)
|
||||||
|
|
||||||
## Anti-Pattern Examples
|
## Anti-Pattern Examples
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -71,6 +71,24 @@ belongs in `[WHEN]`.
|
||||||
Assert.AreEqual(1, TempBuffer.Count(), 'Exactly one tier line expected');
|
Assert.AreEqual(1, TempBuffer.Count(), 'Exactly one tier line expected');
|
||||||
end;
|
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.)
|
||||||
|
|
||||||
## Naming implication
|
## Naming implication
|
||||||
|
|
||||||
The procedure name should make the single WHEN self-evident.
|
The procedure name should make the single WHEN self-evident.
|
||||||
|
|
@ -78,3 +96,5 @@ A name with "And" or "Then" in the middle is a strong signal to split:
|
||||||
|
|
||||||
- `GetPrice_AndDiscount_ReturnsValues` → split
|
- `GetPrice_AndDiscount_ReturnsValues` → split
|
||||||
- `GetPrice_CustomerPrice_ReturnsUnitPrice` → good
|
- `GetPrice_CustomerPrice_ReturnsUnitPrice` → good
|
||||||
|
- `ReceiveThenInvoice_QuantitiesAreCorrect` → legitimate flow test IF the
|
||||||
|
flow-test conditions above are met
|
||||||
|
|
|
||||||
Loading…
Add table
Add a link
Reference in a new issue