Microsoft/bcquality
1
0
Fork 0
mirror of https://github.com/microsoft/BCQuality.git synced 2026-08-06 09:26:52 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions

Add 3 testing knowledge files from book review

Browse source 
- test-one-when-per-test: one WHEN per test, split if multiple actions
- ui-test-codeunit-naming: _UT suffix for TestPage-based codeunits
- test-feature-scenario-tags: [FEATURE]/[SCENARIO] comment structure

Based on patterns from Automatiserede tests med Business Central (Dieringer).

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This commit is contained in:
Michael Dieringer 2026-06-20 21:38:12 +02:00
parent 935d756f05
commit f058095dec
3 changed files with 294 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

108
custom/knowledge/testing/test-feature-scenario-tags.md Normal file
View file

@ -0,0 +1,108 @@
---
bc-version: [all]
domain: testing
keywords: [test, feature, scenario, given, when, then, tags, bdd, atdd, comments, structure]
technologies: [al]
countries: [w1]
application-area: [all]
---
## Description
CURABIS test codeunits follow a four-level comment structure that traces directly
to BDD/ATDD (Behaviour-Driven / Acceptance-Test-Driven Development):
| Tag | Scope | Purpose |
|---|---|---|
| `// [FEATURE]` | Codeunit header | The domain or module under test (e.g. `Find Price`) |
| `// [SCENARIO]` | Per test procedure | One falsifiable business claim |
| `// [GIVEN]` | Inside test body | Preconditions and test data setup |
| `// [WHEN]` | Inside test body | The single action being tested |
| `// [THEN]` | Inside test body | Assertions |
The `[FEATURE]` tag appears once as a comment at the top of the codeunit (before
`{`) and names the functional area — not the object name. The `[SCENARIO]` tag
appears as a comment immediately above each `[Test]` procedure; it describes the
business scenario in plain language, complementing the procedure name.
This structure makes tests readable as a living specification. A product owner
or QA engineer can scan the `[FEATURE]` + `[SCENARIO]` tags to understand
what is covered without reading AL.
## Anti Pattern
```al
// WRONG: no structure — tests as anonymous procedures
codeunit 99006 "Find Price Testing"
{
Subtype = Test;
[Test]
procedure Test1() // what does this test?
begin
// setup mixed with assertions, no clear layers
Customer.Insert(false);
FindPriceMgt.GetSalesPrice(Customer."No.", Item."No.", '', Price, Disc);
Assert.AreEqual(100, Price, '');
end;
}
```
## Best Practice
```al
// [FEATURE] Find Price — price cascade (Customer → Price Group → All Customers)
codeunit 99006 "Find Price Testing"
{
Subtype = Test;
var
WarecoLib: Codeunit "Wareco Test Library";
Assert: Codeunit "Library Assert";
// [SCENARIO] Customer with a specific price list line gets that unit price
[Test]
procedure GetPrice_CustomerPrice_ReturnsUnitPrice()
var
Customer: Record Customer;
Item: Record Item;
UnitPrice, LineDiscPct: Decimal;
begin
// [GIVEN] a customer with a price list line at 100 LCY
WarecoLib.GivenCustomerWithPrice(Customer, Item, '', 100);
// [WHEN]
FindPriceMgt.GetSalesPrice(Customer."No.", Item."No.", '', UnitPrice, LineDiscPct);
// [THEN]
Assert.AreEqual(100, UnitPrice, 'Unit price must match customer price list');
end;
// [SCENARIO] Customer with no price list line falls back to item unit price
[Test]
procedure GetPrice_NoCustomerPrice_FallsBackToItemPrice()
var
Customer: Record Customer;
Item: Record Item;
UnitPrice, LineDiscPct: Decimal;
begin
// [GIVEN] a customer with no price list, item priced at 200
WarecoLib.GivenCustomer(Customer);
WarecoLib.GivenItem(Item, 200);
// [WHEN]
FindPriceMgt.GetSalesPrice(Customer."No.", Item."No.", '', UnitPrice, LineDiscPct);
// [THEN]
Assert.AreEqual(200, UnitPrice, 'Must fall back to item unit price');
end;
}
```
## Relationship to procedure naming
The procedure name and the `[SCENARIO]` comment are complementary — they say the
same thing in different registers:
- Procedure name: `GetPrice_CustomerPrice_ReturnsUnitPrice` — machine-readable,
shows up in test runner output.
- `[SCENARIO]` comment: `Customer with a specific price list line gets that unit price`
— human-readable, business language.
Both must be present. Neither replaces the other.

84
custom/knowledge/testing/test-one-when-per-test.md Normal file
View file

@ -0,0 +1,84 @@
---
bc-version: [all]
domain: testing
keywords: [test, when, scenario, single-action, bdd, atdd, given-when-then]
technologies: [al]
countries: [w1]
application-area: [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
```al
// 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
```al
// 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

102
custom/knowledge/testing/ui-test-codeunit-naming.md Normal file
View file

@ -0,0 +1,102 @@
---
bc-version: [all]
domain: testing
keywords: [test, ui, testpage, naming, suffix, codeunit, page-testing]
technologies: [al]
countries: [w1]
application-area: [all]
---
## Description
Test codeunits that interact with pages via `TestPage` must carry a `_UT` suffix
(Unit Test — UI layer) in their name. This distinguishes them from codeunits that
test business logic directly by calling codeunit/table procedures.
The suffix signals to every reader that the codeunit opens pages, uses
`TestPage.OpenNew()`, reads FactBox parts, or drives field validates through
the page's `OnValidate` triggers — i.e. it exercises the UI layer, not just
the logic layer.
**Convention:**
| Layer tested | Suffix | Example |
|---|---|---|
| Business logic (codeunits, tables) | *(none)* | `FindPriceTesting` |
| Page / UI layer (`TestPage`) | `_UT` | `FindPriceTesting_UT` |
A codeunit may contain **only** UI tests or **only** logic tests — never mix both
in the same codeunit.
## Anti Pattern
```al
// WRONG: UI test codeunit without _UT suffix
codeunit 99007 "Find Price Page Testing"
{
Subtype = Test;
// contains TestPage calls — should be named "Find Price Testing_UT"
...
}
```
```al
// WRONG: mixing direct codeunit calls and TestPage calls in the same codeunit
codeunit 99007 "Find Price Testing"
{
Subtype = Test;
[Test]
procedure GetPrice_LogicTest() // logic test — fine here
begin
FindPriceMgt.GetSalesPrice(...);
end;
[Test]
procedure Page_ShowsPrice_UT() // UI test — belongs in separate _UT codeunit
var
FindPricePage: TestPage "Find Price";
begin
FindPricePage.OpenNew();
...
end;
}
```
## Best Practice
```al
// CORRECT: separate codeunits per layer
// Logic tests — no _UT suffix
codeunit 99006 "Find Price Testing"
{
Subtype = Test;
[Test]
procedure GetPrice_CustomerPrice_ReturnsUnitPrice()
begin
FindPriceMgt.GetSalesPrice(...);
end;
}
// UI tests — _UT suffix
codeunit 99007 "Find Price Testing_UT"
{
Subtype = Test;
[Test]
procedure Page_EnterCustomerAndItem_FactBoxShowsPrice()
var
FindPricePage: TestPage "Find Price";
begin
FindPricePage.OpenNew();
FindPricePage.CustomerNo.SetValue(Customer."No.");
FindPricePage.ItemNo.SetValue(Item."No.");
Assert.AreEqual('100,00', FindPricePage.FindPriceInfo.UnitPrice.Value(), '');
end;
}
```
## Object ID allocation
Allocate adjacent IDs for the two related codeunits (e.g. 99006 logic, 99007 UI)
so they sort together in the object list and their relationship is self-evident.