bcquality/microsoft/knowledge/testing/table-relation-test-exclude-known-invalid-relations-via-event.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

1.7 KiB

bc-version domain keywords technologies countries application-area
all
testing
table-relation-test
tablerelationsmetadata
onafterremovetablerelation
field-length
field-type
al
w1
all

Exclude a known-valid TableRelation exception via OnAfterRemoveTableRelation

Description

Codeunit 134926 "Table Relation Test" (shipped in BCApps' test app — only consumers that depend on the BC test libraries can subscribe to it) reads Table Relations Metadata tenant-wide across every installed app, not just the current one, and fails the moment a related field's type or length doesn't match what the relation requires — the related field must match the largest related field's length, and its type must match (except a field may relate to both Code and Text, which resolves to Text). A field with a legitimate, intentional relation shape has no per-field override in its own object definition; the check runs with no built-in escape hatch.

Best Practice

Subscribe to OnAfterRemoveTableRelation and call the codeunit's own RemoveTableRelation(TableRelationsMetadata, TableID, FieldID, RelatedTableID, RelatedFieldID) to strike the one known-valid relation before the test evaluates it, scoped as narrowly as the exception actually is.

See sample: table-relation-test-exclude-known-invalid-relations-via-event.good.al.

Anti Pattern

Excluding an entire table's relations (or disabling the whole test codeunit) to work around one known exception. This discards the check's coverage for every other relation on that table, or in the app, not just the one that needed an exception.

See sample: table-relation-test-exclude-known-invalid-relations-via-event.bad.al.