3 AL/BC patterns from CURABIS's internal automated-testing training material

[Michael Dieringer (MichaelDieringer)]

Summary

Third batch from CURABIS ApS, mined from CURABIS's own internal Academy course book on automated/BDD testing in Business Central. Same format as #156/#157 (6-key frontmatter, Description/Best Practice/Anti Pattern, sibling .good.al/.bad.al samples, no fenced code in the .md).

• data-modeling (1): after posting a sales order with Ship and Invoice together, the resulting Item Ledger Entry carries the shipment's document number (Sales Header."Last Shipping No."), not the posted invoice number — a lookup filtered on the invoice number silently matches zero rows. Sales-specific; purchase combined posting (Receive+Invoice) uses different fields.
• testing (3): verify a field's actual rendered UI state with TestPage field .Visible()/.Enabled(), and its editability specifically with .Editable() opened via OpenEdit() — these are distinct states requiring different verification. Generate test fixture values via the right LibraryUtility helper for the guarantee actually needed: GenerateRandomCodeWithLength/GenerateRandomCode20 when uniqueness against the real table must be verified, GenerateGUID() (untruncated, full-length fields only) or GenerateRandomCode/GenerateRandomXMLText for incidental values — not hardcoded literals or a truncated GUID.

Most of the source book turned out to be BDD philosophy and CURABIS process content that doesn't clear BCQuality's admission test — these 4 are the genuinely atomic, non-obvious AL-specific patterns that survived a full read-through, checked against the current microsoft/knowledge/ corpus and CURABIS's own two prior PRs for overlap.

Test plan

• CI frontmatter/format validation passes
• Domain-owning reviewers confirm placement and accuracy per file

🤖 Generated with Claude Code

[Jesper Schulz-Wedde (JesperSchulz)]

The Item Ledger Entry pattern checks out against current BCApps source: combined Ship+Invoice posting stamps the item journal line with the posted shipment number, while LibrarySales.PostSalesDocument returns Last Posting No. because the invoice branch overwrites its return-field selection.

I found two accuracy blockers in the testing guidance (called out inline) and one consumption gap: the current al-testing-review worklist has no GenerateGUID/CopyStr or TestPage Visible/Enabled/Editable cues or targeted checks, and al-data-modeling-review scopes relevance to setup/master-table surfaces without any Item Ledger Entry/posting cue. Please wire all three articles into their corresponding review-skill worklists so agents can actually select them; coordinate this with #155, whose contracts state that targeted checks cover every current article.

The CLA is also still pending. Because the PR says the material was mined from CURABIS's internal Academy course book, the contributor needs to use the applicable company/employer declaration, confirm authorization to contribute the derived material, and make any third-party-material disclosure required by the CLA.

[Michael Dieringer (MichaelDieringer)]

@microsoft-github-policy-service agree [company="CURABIS ApS"]

[Michael Dieringer (MichaelDieringer)]

@microsoft-github-policy-service agree company="CURABIS ApS"

[Jesper Schulz-Wedde (JesperSchulz)]

Follow-up after ab4ed50: the Visible/Enabled scope and the Editable/OpenEdit distinction now look sound, and the Item Ledger Entry article is reasonable for combined sales Ship+Invoice posting. The three remaining substantive issues are inline.

Please also update the PR description: it still advertises the superseded GenerateGUID() + CopyStr recommendation and no longer describes the current change.

[Michael Dieringer (MichaelDieringer)]

Jesper Schulz-Wedde (@JesperSchulz) Addressed in 1d05811 (pushed 2026-09-08): the 4 inline issues above, plus the PR description — updated to describe the actual current recommendation (pick the LibraryUtility helper by the guarantee needed) instead of the superseded blanket GenerateGUID()+CopyStr line. Ready for another look whenever you have time.

[Jesper Schulz-Wedde (JesperSchulz)]

Thank you—the helper behavior, fixture implementation, review relevance, sales-only posting scope, and PR description are all much improved. This PR is very close.

Two factual points remain in the uniqueness article. We recognize that another round is inconvenient, but these claims directly determine which test code agents will flag and which helper guarantees they will trust, so they need to be precise. We have limited the feedback to those two points and omitted optional cleanup.

[Jesper Schulz-Wedde (JesperSchulz)]

Re-reviewed the exact latest head against current main, current BCApps test-library source, all prior threads, and the repository validators. The previously resolved helper/fixture/purchase-scope threads remain fixed; the two still-open uniqueness threads remain necessary.

Three additional blockers surfaced in the current tree:

1. item-ledger-entry-document-no-follows-last-shipping-no.bad.al calls FindSet() without consuming its optional Boolean. On an empty result AL raises a runtime error; it is not the silent zero-row behavior claimed by the article. Return/consume the Boolean in both fixtures (or correct the prose) so the sample demonstrates the claimed behavior.
2. al-data-modeling-review.md still declares the leaf not-applicable outside setup/master/key/numbering/block/audit surfaces (intro and outcome), which excludes the new sales-posting/Item Ledger Entry lookup despite its targeted cue. Add that surface to both scope clauses.
3. Current main requires READ-convention Markdown links to sibling samples. All eight new See sample: ...references are plain code spans, so the exact virtual-merge `Test-ReviewFixtures.ps1` fails with “Sample is not linked by its article.” Convert each toname.good.al`` / bad equivalent.

Existing GitHub checks are green but predate the current-base validator. On the virtual merge, frontmatter and deterministic index checks pass; fixture validation fails at the links. After simulating only those eight link fixes, all 46 default cases pass, and a 50-case targeted run confirms all four new articles survive deterministic candidate ranking.

[Michael Dieringer (MichaelDieringer)]

Thanks Jesper. Addressed all items from the 2026-09-15 re-review:

The two still-open uniqueness threads:

• Narrowed the collision rule (Description, Anti Pattern, and the al-testing-review.md worklist cue) to primary-key fields or values the test explicitly relies on as unique lookup identifiers. An ordinary descriptive field carries no such constraint, so a hardcoded or deterministic value there is no longer flagged.
• Corrected GenerateRandomCode: rechecked against current LibraryUtility.Codeunit.al — it opens its target table as a temporary RecordRef, which starts and stays empty, so its repeat...until RecRef.IsEmpty() always exits after one iteration and never retries, even within a single call. It returns the rightmost FieldRef.Length characters of GenerateGUID()'s sequential GU00000000–GU99999999 series, so for a short field that window cycles (Code[1] repeats every 10 calls, Code[2] every 100). No longer describes it as collision-free at any scope — just a finite short-field namespace with low collision chance, distinct from the real table-checking helpers.

The three new blockers:

1. Both item-ledger-entry-document-no-follows-last-shipping-no fixtures called FindSet() without consuming its optional Boolean, which raises a runtime error on an empty result — the opposite of the article's own claimed "silently matches zero rows" behavior. Fixed with if ItemLedgerEntry.FindSet() then;, matching the existing idiom in guard-database-reads.good.al.
2. al-data-modeling-review.md still declared not-applicable outside setup/master/key/numbering/block/audit surfaces in both the intro and the outcome clause. Added dimension wiring, posting-routine structure, and Item Ledger Entry document-number lookups to both.
3. Converted all 8 plain-backtick sample references across the 4 new articles to the READ-convention markdown-link form.

Rebased onto current main (one conflict in al-data-modeling-review.md's intro wording — merged, kept the upstream phrasing plus this PR's domain additions). All local validators pass: frontmatter, knowledge-index, knowledge-retrieval (337 articles / 565 samples), review-fixtures (108 cases / 20 leaf domains), skill-index.

[Jesper Schulz-Wedde (JesperSchulz)]

One merge-critical contradiction remains in al-testing-review.md: it presents GenerateRandomCode20 as compliant for a shorter field. That helper is intended for Code[20]; short fields can truncate the changing portion and make uniqueness retries pathological. This also contradicts the new article, which correctly scopes it to Code[20].

Please route short fields to GenerateRandomCodeWithLength and reserve GenerateRandomCode20 for Code[20] fields. The prior uniqueness, FindSet, scope, relevance, sample-link, description, and CLA blockers otherwise appear resolved.

[Jesper Schulz-Wedde (JesperSchulz)]

This is very close now. Both earlier discussion threads are resolved and closed; only the focused helper-selection contradiction from the latest review remains.

[Michael Dieringer (MichaelDieringer)]

Thanks Jesper. Narrowed the `al-testing-review.md` cue — it no longer presents `GenerateRandomCode20` as an equal alternative to `GenerateRandomCodeWithLength` for a shorter field. Verified against `LibraryUtility.Codeunit.al`: `GenerateRandomCode20` truncates `GenerateGUID()`'s sequential value down to the field's length via `PadStr`, keeping the leftmost (slowest-changing) characters — so for a field shorter than 20, its retry loop can churn through the same truncated prefix for a long time, exactly the pathological-retries risk you flagged. `GenerateRandomCodeWithLength` is now the only compliant route for shorter fields; `GenerateRandomCode20` is scoped to `Code[20]`, matching what the article itself already said. Validators pass clean.

[Jesper Schulz-Wedde (JesperSchulz)]

The remaining helper-selection contradiction is resolved: short fields now route to GenerateRandomCodeWithLength, while GenerateRandomCode20 is limited to Code[20]. No new merge-critical issue found.