bcquality/microsoft/knowledge/testing/confirm-needs-strsubstno-before-confirmhandler-sees-substituted-text.md
Michael Dieringer dcd79afc08 Address Jesper Schulz-Wedde's review on PR #159
- transactionmodel-attribute-governs-test-transactions.md: the "Commit
  causes an error" behavior is specific to an explicitly declared
  AutoRollback attribute. A test method with no TransactionModel
  attribute at all is a distinct, valid shape — BCApps' own
  codeunit 134915 "ERM Online Mapping Setup" commits inside a lazy
  Initialize() with no attribute declared, cleaning up via a manual
  asserterror at the end. Evidence for commit-shared-test-fixture-
  inside-lazy-initialize.md (this PR), which is correct as submitted.
- confirm-needs-strsubstno-before-confirmhandler-sees-substituted-text.md:
  reframe as a known, unconfirmed-fix platform defect
  (microsoft/ALAppExtensions#23935) rather than designed behavior; add
  the Message/MessageHandler asymmetry as supporting evidence.
- table-relation-test-exclude-known-invalid-relations-via-event.md:
  note the test-app-only consumer dependency; correct "walks every
  TableRelation field property in the app" to the actual tenant-wide
  Table Relations Metadata scope across installed apps.
- Wire confirm-needs-strsubstno, commit-shared-test-fixture-inside-
  lazy-initialize, and table-relation-test-exclude-known-invalid-
  relations-via-event into al-testing-review.md's candidate-selection
  cues.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-21 22:48:58 +02:00

30 lines
2 KiB
Markdown

---
bc-version: [all]
domain: testing
keywords: [confirm, confirmhandler, strsubstno, placeholder, question, substitution]
technologies: [al]
countries: [w1]
application-area: [all]
---
# Build the Confirm message with StrSubstNo, or a ConfirmHandler sees the raw template
## Description
`Confirm`'s placeholder-substitution overload — `Confirm('text %1', false, Value)` — substitutes the placeholder only for the dialog a real user sees. Inside a `[ConfirmHandler]`, the `Question` parameter received is the literal, unsubstituted template string (`'text %1'`), not the value-filled text. This is a reported platform defect (microsoft/ALAppExtensions#23935), not documented or intended behavior — treat it as a known, unconfirmed-fix issue rather than a permanent platform rule; if it is ever fixed, this workaround becomes unnecessary rather than wrong. Notably, `Message`/`[MessageHandler]` substitutes correctly — only `Confirm` is affected, which is itself evidence this is a bug rather than a deliberate design choice. A test that asserts `Question` against the expected substituted message either fails outright or silently checks the wrong thing.
## Best Practice
When a `ConfirmHandler` needs to assert on the actual message text, build the string with `StrSubstNo(Text, Value)` in the production code first, and pass the already-substituted string to `Confirm()` with no further placeholder arguments.
See sample: `confirm-needs-strsubstno-before-confirmhandler-sees-substituted-text.good.al`.
## Anti Pattern
Calling `Confirm('text %1', false, Value)` and then asserting the substituted text against `Question` inside a `[ConfirmHandler]`. `Question` holds the raw `'text %1'` template, so the assertion never matches the intended message.
See sample: `confirm-needs-strsubstno-before-confirmhandler-sees-substituted-text.bad.al`.
## Source
Reported by Luc van Vugt: https://github.com/microsoft/ALAppExtensions/issues/23935 — an internal Microsoft bug was filed from that report; the issue's fix status is not confirmed as of this writing.