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

Add 18 community AL/BC patterns across style, data-modeling, web-services, appsource, breaking-changes, performance, and testing

Browse source 
Contributed by CURABIS ApS, generalized from patterns observed across real AppSource/PTE development. Each article follows the knowledge file format (frontmatter, Description/Best Practice/Anti Pattern, sibling .good.al/.bad.al samples).
This commit is contained in:
Michael Dieringer 2026-09-04 20:43:00 +02:00
parent 07e324ddbc
commit 057e17c202
52 changed files with 1109 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

28
microsoft/knowledge/data-modeling/testfield-required-setup-field-before-use.md Normal file
View file

@ -0,0 +1,28 @@
---
bc-version: [all]
domain: data-modeling
keywords: [testfield, setup-table, configuration, mandatory-field, silent-fallback, correctness]
technologies: [al]
countries: [w1]
application-area: [all]
---
# TestField a Setup-Table Value Before Using It in a Correctness-Critical Branch
> Contributions welcome — open a PR to refine or extend this article.
## Description
A procedure that reads a field from a setup or configuration table inside a branch where the surrounding logic has already decided that value is required needs to guard against it being blank. A common anti-pattern silently treats "blank" as "feature not wanted": it checks the field for emptiness and falls through to a default instead of raising an error. `Get()` succeeding on the setup record only proves the record exists, not that the specific field was ever configured, so the fallback path makes a missing configuration indistinguishable from a deliberate one — and the wrong outcome, especially in financial, tax, or compliance postings, surfaces silently rather than as a crash a tester would notice.
## Best Practice
Once a business rule has decided that a setup-table field's value is required for a branch to behave correctly, call `TestField` on it before use, even though a plain read would "work" by returning a blank or zero without erroring. Write a test that blanks the setup field and asserts the resulting error, so the guard itself is verified rather than merely present.
See sample: `testfield-required-setup-field.good.al`.
## Anti Pattern
Reading a required setup-table field behind a presence check that falls through to a default value instead of erroring. This looks defensive because it never crashes, but it converts "administrator forgot to configure this" into "system silently did something else" — worse than a hard failure, because nobody is told anything went wrong.
See sample: `testfield-required-setup-field.bad.al`.