mirror of
https://github.com/microsoft/BCQuality.git
synced 2026-10-07 15:46:55 +01:00
Add 3 more AL/BC patterns from CURABIS Academy testing course material
Third batch from CURABIS ApS: item-ledger-entry document-no lookup after Ship-and-Invoice posting, TestPage.Visible()/.Enabled() as the mechanism for verifying field UI state, and LibraryUtility.GenerateGUID() for collision-free test fixture values.
This commit is contained in:
parent
07e324ddbc
commit
1028aacd4f
9 changed files with 155 additions and 0 deletions
|
|
@ -0,0 +1,26 @@
|
|||
---
|
||||
bc-version: [all]
|
||||
domain: testing
|
||||
keywords: [testpage, visible, enabled, ui-state, headless-test, field-verification]
|
||||
technologies: [al]
|
||||
countries: [w1]
|
||||
application-area: [all]
|
||||
---
|
||||
|
||||
# Verify field visibility and editability with TestPage.Visible()/.Enabled()
|
||||
|
||||
## Description
|
||||
|
||||
A UI test codeunit does not need to inspect table or page properties indirectly to confirm a field is shown or editable under given conditions. The `TestPage` object exposes a `Visible()` and an `Enabled()` function on each field, reflecting the page's actual rendered state, callable directly from a `[Test]` procedure after `OpenView()`.
|
||||
|
||||
## Best Practice
|
||||
|
||||
Open the `TestPage`, navigate to the relevant record if needed, then assert against `TestPageField.Visible()` and `TestPageField.Enabled()` to verify the field's UI state, rather than checking an unrelated table/page property or skipping the check.
|
||||
|
||||
See sample: `use-testpage-visible-enabled-to-verify-field-ui-state.good.al`.
|
||||
|
||||
## Anti Pattern
|
||||
|
||||
A test that opens the `TestPage` but never asserts against `Visible()`/`Enabled()` on the field in question — confirming only that the page opens, not that the field behaves as expected.
|
||||
|
||||
See sample: `use-testpage-visible-enabled-to-verify-field-ui-state.bad.al`.
|
||||
Loading…
Add table
Add a link
Reference in a new issue