mirror of
https://github.com/microsoft/BCQuality.git
synced 2026-10-05 14:46:55 +01:00
Fix ten focused correctness items plus sample links from Jesper's 2026-09-15 re-review
Six carried-over threads: - api-page-least-privilege-write-access fixtures: added the mandatory EntityName/EntitySetName properties (AL0485). - pages-must-not-contain-business-logic fixtures: Sales Line has no "Total Amount" field; replaced with the real "Line Amount" (field 103). - test-feature-scenario-tags.good.al and test-one-when-per-test.good.al: CreatePriceHeader leaves a price list in Draft status, which price calculation ignores. Added Validate(Status, Active) + Modify before the sales line that depends on it. Verified Status field/enum against PriceListHeader.Table.al and PriceStatus.Enum.al in the BCApps clone. - exposed-objects-must-be-in-a-permission-set.md: a published codeunit is a SOAP endpoint (SOAP is deprecated), not OData - Page/Query are the OData object types. Corrected and pointed new integrations at API pages/queries instead. - al-error-handling-review.md: the log-writes-must-survive-rollback cue selected on Session.StartSession, which only appears in the compliant fix, never in the anti-pattern - the bad fixture could never be worklisted. Recued on the actual risk shape (log insert around a failed TryFunction/GetLastError* path, then raise/propagate), with StartSession as an explicit compliant discriminator instead. - page-design-must-match-bc-page-type-conventions.md: the enum value is NavigatePage, not Navigate; noted the type list is a selected subset, not an exhaustive PageType catalogue (PromptDialog, ConfigurationDialog, UserControlHost, XmlPort also exist, out of this article's scope). Four new correctness gaps: - release-must-update-app-version.md: "the version is the only identity" was backwards - id is the app's stable identity, version identifies a release/code-state of it. - defensive-vs-offensive-code-must-match-blast-radius.good.al: the "low blast radius" example had no else branch, so a failed Customer.Get() left the field at its prior/default value instead of the explicit chosen fallback the article claims to demonstrate. Added the else. - bcpt-scenarios-must-be-app-specific.good.al: InitTest and both measured StartScenario/EndScenario sections were empty/comment-only, so the "app-specific" fixture measured no actual work. Filled in a real, self-contained header+line creation path. - upgrade-tag-logic-must-not-nest-deeply.good.al: the flattened version dropped both safety conditions the bad fixture had (Discount % = 0, nonblank posting group), silently changing behavior instead of just removing nesting. Extracted the guarded update into a helper with both conditions preserved as early exits. Also converted this PR's remaining plain-backtick "See sample:" sample references (16 articles) to the READ-convention markdown-link form, matching the fix already made on #156/#158. Rebased onto upstream/main (conflicts in al-ui-review.md, al-style-review.md, al-upgrade-review.md against merged upstream PRs - all additive, both sides' worklist cues retained).
This commit is contained in:
Michael Dieringer
parent
3842ef7138
commit
67962727f6
27 changed files with 96 additions and 47 deletions
|
|
@ -13,22 +13,38 @@ codeunit 50100 "BCPT Create Service Request" implements "BCPT Test Param. Provid
|
|||
|
||||
var
|
||||
GlobalBCPTTestContext: Codeunit "BCPT Test Context";
|
||||
CustomerNo: Code[20];
|
||||
NextNo: Integer;
|
||||
IsInitialized: Boolean;
|
||||
|
||||
local procedure InitTest()
|
||||
var
|
||||
Customer: Record Customer;
|
||||
begin
|
||||
// Set up any required configuration
|
||||
Customer.FindFirst();
|
||||
CustomerNo := Customer."No.";
|
||||
end;
|
||||
|
||||
local procedure CreateServiceRequest(var BCPTTestContext: Codeunit "BCPT Test Context")
|
||||
var
|
||||
ServiceRequestHeader: Record "Service Request Header";
|
||||
ServiceRequestLine: Record "Service Request Line";
|
||||
begin
|
||||
BCPTTestContext.StartScenario('Create Service Request Header');
|
||||
// ... create the service request
|
||||
NextNo += 1;
|
||||
ServiceRequestHeader.Init();
|
||||
ServiceRequestHeader."No." := CopyStr(Format(NextNo), 1, MaxStrLen(ServiceRequestHeader."No."));
|
||||
ServiceRequestHeader.Validate("Customer No.", CustomerNo);
|
||||
ServiceRequestHeader.Insert(true);
|
||||
BCPTTestContext.EndScenario('Create Service Request Header');
|
||||
BCPTTestContext.UserWait();
|
||||
|
||||
BCPTTestContext.StartScenario('Add Service Request Line');
|
||||
// ... add a line
|
||||
ServiceRequestLine.Init();
|
||||
ServiceRequestLine."Document No." := ServiceRequestHeader."No.";
|
||||
ServiceRequestLine."Line No." := 10000;
|
||||
ServiceRequestLine.Description := 'Performance test line';
|
||||
ServiceRequestLine.Insert(true);
|
||||
BCPTTestContext.EndScenario('Add Service Request Line');
|
||||
end;
|
||||
|
||||
|
|
|
|||
|
|
@ -17,10 +17,10 @@ A PerformanceTest app that ships with only the generic Microsoft BCPT samples (c
|
|||
|
||||
For every major business flow the extension adds, create a matching `BCPT*` scenario codeunit implementing `"BCPT Test Param. Provider"`, building its own test data in a local `InitTest()` procedure rather than depending on hardcoded records. Beyond that shared shape, the interface details are context-dependent, not fixed requirements: most of Microsoft's own shipped BCPT samples declare `SingleInstance = true`, but `codeunit "BCPT Create Customer"` does not, relying instead on `OnRun` calling `InitTest()` unconditionally every run. Likewise, wrapping the operation under test in `BCPTTestContext.StartScenario()` / `EndScenario()` is a real, available pattern for splitting one codeunit's run into several separately measured steps — useful when a regression in one step should not hide inside a coarser, whole-`OnRun` measurement — but it is not what every sample does; `"BCPT Create Customer"` measures its entire `OnRun` as a single implicit scenario and never calls `StartScenario`/`EndScenario` at all. Choose per-step scenarios when step-level granularity matters to the flow being tested; otherwise a single measured `OnRun` is a legitimate, simpler choice.
|
||||
|
||||
See sample: `bcpt-scenarios-must-be-app-specific.good.al`.
|
||||
See sample: [`bcpt-scenarios-must-be-app-specific.good.al`](bcpt-scenarios-must-be-app-specific.good.al).
|
||||
|
||||
## Anti Pattern
|
||||
|
||||
A PerformanceTest app whose only scenario codeunits are copies of Microsoft's shipped samples (creating a standard sales order, opening the standard customer list) tests the platform, not the extension. Any regression in the extension's own posting logic, calculations, or pages goes unmeasured and unnoticed.
|
||||
|
||||
See sample: `bcpt-scenarios-must-be-app-specific.bad.al`.
|
||||
See sample: [`bcpt-scenarios-must-be-app-specific.bad.al`](bcpt-scenarios-must-be-app-specific.bad.al).
|
||||
|
|
|
|||
|
|
@ -17,10 +17,10 @@ A `[GIVEN]` block is only correct if it sets up every precondition the code unde
|
|||
|
||||
For a posting test, set up the full posting-group chain the document requires (e.g. customer/vendor posting group, gen. business/product posting group, VAT posting setup), the setup records the specific posting path reads, and an explicit date when the path is date-sensitive — a missing link surfaces as an unrelated G/L error, not a meaningful test failure. For a report test that claims to verify filtering or dataset logic, include both a record that should be included and one that should be excluded, plus any request-page parameter or FlowField the report's logic branches on. A report test that only claims to run without error is exempt from the include/exclude pairing, but it must say so in its scenario name or comment — an unlabelled single-record `[GIVEN]` is ambiguous about which claim it is making, and that ambiguity is itself the defect.
|
||||
|
||||
See sample: `given-blocks-must-cover-full-precondition-chain.good.al`.
|
||||
See sample: [`given-blocks-must-cover-full-precondition-chain.good.al`](given-blocks-must-cover-full-precondition-chain.good.al).
|
||||
|
||||
## Anti Pattern
|
||||
|
||||
A posting test whose `[GIVEN]` creates only the sales header, relying on whatever posting groups happen to exist in the test company. A report test whose `[GIVEN]` creates only matching records, so the report "passes" whether or not its filter logic does anything at all.
|
||||
|
||||
See sample: `given-blocks-must-cover-full-precondition-chain.bad.al`.
|
||||
See sample: [`given-blocks-must-cover-full-precondition-chain.bad.al`](given-blocks-must-cover-full-precondition-chain.bad.al).
|
||||
|
|
|
|||
|
|
@ -28,6 +28,9 @@ codeunit 50103 "Item Price Testing"
|
|||
LibraryPriceCalculation.CreateSalesPriceLine(
|
||||
PriceListLine, PriceListHeader.Code, "Price Source Type"::Customer, Customer."No.",
|
||||
"Price Asset Type"::Item, Item."No.");
|
||||
// CreatePriceHeader leaves the list in Draft status, which price calculation ignores.
|
||||
PriceListHeader.Validate(Status, PriceListHeader.Status::Active);
|
||||
PriceListHeader.Modify(true);
|
||||
// [WHEN] a sales line is created for that customer and item
|
||||
LibrarySales.CreateSalesDocumentWithItem(
|
||||
SalesHeader, SalesLine, SalesHeader."Document Type"::Order, Customer."No.", Item."No.", 1, '', 0D);
|
||||
|
|
|
|||
|
|
@ -17,10 +17,10 @@ Test codeunits are easier to trust and to review when they carry a four-level co
|
|||
|
||||
Put `[FEATURE]` as a comment before the codeunit's opening brace, naming the domain rather than the object — Microsoft's own guidance allows setting it once for the whole codeunit, inherited by every test in it. Put `[SCENARIO]`, matching the current BCApps corpus, as the first comment inside each test procedure's body (after `begin`), describing the scenario in business language that complements — not duplicates — the procedure name, followed by `[GIVEN]` marking the precondition setup, `[WHEN]` marking the single action under test, and `[THEN]` marking the assertions. The procedure name stays the machine-readable identity shown in test-runner output; the `[SCENARIO]` comment stays the human-readable one. Neither replaces the other.
|
||||
|
||||
See sample: `test-feature-scenario-tags.good.al`.
|
||||
See sample: [`test-feature-scenario-tags.good.al`](test-feature-scenario-tags.good.al).
|
||||
|
||||
## Anti Pattern
|
||||
|
||||
A test procedure with no `[FEATURE]`/`[SCENARIO]`/`[GIVEN]`/`[WHEN]`/`[THEN]` structure, setup mixed freely with assertions, and a procedure name like `Test1` that says nothing about what is being verified. Nothing in the codeunit tells a reader what business rule it exists to protect.
|
||||
|
||||
See sample: `test-feature-scenario-tags.bad.al`.
|
||||
See sample: [`test-feature-scenario-tags.bad.al`](test-feature-scenario-tags.bad.al).
|
||||
|
|
|
|||
|
|
@ -16,6 +16,9 @@ begin
|
|||
LibraryPriceCalculation.CreateSalesPriceLine(
|
||||
PriceListLine, PriceListHeader.Code, "Price Source Type"::Customer, Customer."No.",
|
||||
"Price Asset Type"::Item, Item."No.");
|
||||
// CreatePriceHeader leaves the list in Draft status, which price calculation ignores.
|
||||
PriceListHeader.Validate(Status, PriceListHeader.Status::Active);
|
||||
PriceListHeader.Modify(true);
|
||||
// [WHEN]
|
||||
LibrarySales.CreateSalesDocumentWithItem(
|
||||
SalesHeader, SalesLine, SalesHeader."Document Type"::Order, Customer."No.", Item."No.", 1, '', 0D);
|
||||
|
|
|
|||
|
|
@ -17,13 +17,13 @@ This is a testing-design practice, not a BC platform requirement — no AL API e
|
|||
|
||||
Give each test one `[WHEN]` and one focused claim. A procedure name containing "And" or "Then" in the middle (`GetPrice_AndDiscount_ReturnsValues`) is a strong signal the test should be split.
|
||||
|
||||
See sample: `test-one-when-per-test.good.al`.
|
||||
See sample: [`test-one-when-per-test.good.al`](test-one-when-per-test.good.al).
|
||||
|
||||
## Anti Pattern
|
||||
|
||||
A test that performs a first action, then a second unrelated action, then asserts on both — mixing two falsifiable claims into one procedure so a failure can't tell you which action broke.
|
||||
|
||||
See sample: `test-one-when-per-test.bad.al`.
|
||||
See sample: [`test-one-when-per-test.bad.al`](test-one-when-per-test.bad.al).
|
||||
|
||||
## Flow tests — a deliberate exception
|
||||
|
||||
|
|
|
|||
|
|
@ -17,10 +17,10 @@ A test codeunit that drives pages through `TestPage` — opening pages, reading
|
|||
|
||||
Keep UI-layer (`TestPage`-driven) and logic-layer tests in separate codeunits regardless of naming. Projects that adopt a `_UT`-style suffix convention should apply it consistently to every UI-layer test codeunit, keep the corresponding logic-only codeunit unsuffixed, and document the convention where the team's other naming rules live.
|
||||
|
||||
See sample: `ui-test-codeunit-naming.good.al`.
|
||||
See sample: [`ui-test-codeunit-naming.good.al`](ui-test-codeunit-naming.good.al).
|
||||
|
||||
## Anti Pattern
|
||||
|
||||
One codeunit that mixes a direct logic-call test and a `TestPage`-driven test side by side — a failing test no longer tells a reader which layer actually broke. On a project that has adopted the `_UT` convention, a UI-layer codeunit missing the suffix is also an instance of this anti-pattern; on a project that has not adopted it, the suffix itself is not required.
|
||||
|
||||
See sample: `ui-test-codeunit-naming.bad.al`.
|
||||
See sample: [`ui-test-codeunit-naming.bad.al`](ui-test-codeunit-naming.bad.al).
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue