db9c0f275a
- use-generateguid-for-unique-test-fixture-values.md: narrowed the collision rule to primary-key/unique-lookup fields - an ordinary descriptive field carries no uniqueness constraint, so a hardcoded or deterministic value there isn't the anti-pattern (the article and its al-testing-review.md worklist cue both said "primary-key or descriptive field"). Also corrected GenerateRandomCode: it opens its target table as a temporary RecordRef that starts and stays empty, so its repeat/until loop always exits after one iteration and never retries even within a single test run - the "non-colliding within a test run" claim was false. It's the rightmost N characters of GenerateGUID()'s sequential series, so a short field's value cycles (Code[1] repeats every 10 calls, Code[2] every 100). Verified against LibraryUtility.Codeunit.al in the BCApps reference clone. - item-ledger-entry-document-no-follows-last-shipping-no: both fixtures called FindSet() without consuming its optional Boolean, which raises a runtime error on an empty result set - the opposite of the article's own claimed "silently matches zero rows, no error" behavior. Wrapped in `if ... then;` per the existing guard-database-reads.good.al idiom. - al-data-modeling-review.md: widened both not-applicable scope clauses (intro and outcome) to include dimension wiring, posting- routine structure, and Item Ledger Entry document-number lookups - the leaf declared itself not-applicable outside setup/master/key/ numbering/block/audit surfaces despite having a targeted cue for this PR's own new article. - Converted this PR's 8 plain-backtick "See sample: `x.good.al`." references (across all 4 new articles) to the READ-convention markdown-link form required by Knowledge-Retrieval.ps1. Rebased onto upstream/main (one conflict in al-data-modeling-review.md intro wording, merged).
1.4 KiB
| bc-version | domain | keywords | technologies | countries | application-area | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
testing |
|
|
|
|
Verify field editability with TestPage.Editable(), opened in edit mode
Description
Whether a field can actually be changed is a distinct state from whether it is shown or enabled — Editable() and Enabled() are separate TestField functions. Verifying editability also requires opening the TestPage with OpenEdit(), not OpenView(): OpenView() opens the page in view mode, so it does not exercise the field's own conditional editability logic the way an actual edit-mode session does.
Best Practice
Open the TestPage with OpenEdit(), navigate to the relevant record, then assert against TestPageField.Editable() to verify whether the field can be changed under the given precondition.
See sample: use-testpage-editable-to-verify-field-editability.good.al.
Anti Pattern
Asserting Enabled() (or checking nothing at all) when the actual claim is about editability, or opening the page with OpenView() when the field's editability depends on business logic that only applies in edit mode.
See sample: use-testpage-editable-to-verify-field-editability.bad.al.