mirror of
https://github.com/microsoft/BCQuality.git
synced 2026-10-05 14:46:55 +01:00
The narrowed UI-handler guidance still stated the execution rule without the qualifier the linked Microsoft reference uses. The article said every listed handler must execute at least once, and the testing leaf skill asked for `[HandlerFunctions(...)]` to match the invoked handlers exactly. The reference says every *nonoptional* listed handler must execute, and that send-notification and recall-notification handlers can be optional. As written, an agent could flag a deliberately unused optional notification handler. The discriminator is narrower than the handler type. Both `[SendNotificationHandler([HandlerIsOptional: Boolean])]` and `[RecallNotificationHandler([HandlerIsOptional: Boolean])]` take an explicit optionality argument, so `[SendNotificationHandler(true)]` is exempt while the same attribute written without the argument stays nonoptional like every other handler type. Keying the exemption on the argument rather than the type keeps it checkable from the diff and avoids the opposite false positive, where an agent stops flagging genuinely nonoptional notification handlers. Changes: - The article now states the nonoptional qualifier, explains that optionality is declared rather than inferred, and adds an explicit do-not-flag clause. That clause also forbids proposing removal, because the listed entry is what keeps the test passing on the runs where the notification does fire. - The testing leaf skill carries the same boundary in its `ui-handlers-in-tests` cue, and its mechanical-fix list no longer allows removing a listed optional notification handler as a one-click suggestion. - `SendNotificationHandler` and `RecallNotificationHandler` were missing from the skill's testing token list, so notification handlers were not reliably surfaced to the relevance step at all. Both are now listed. - The good sample gains a test that lists an unreached `[SendNotificationHandler(true)]`; the bad sample gains the mirror image, an unreached `[SendNotificationHandler]` with no optionality argument. The pair differs only by that argument, which is the point. - `evaluation/review-fixtures.json` pins the testing domain to `ui-handlers-in-tests` so the boundary is exercised: the good sample is the clean control at `minimumCleanRate` 1.0 and the bad sample is the expected finding. Keywords were retagged with `notification` and `optional-handler`. validate_frontmatter.py reports 0 errors; Test-ReviewFixtures.ps1 passes with 32 cases across 16 leaf domains and resolves the testing fixture to this article.
49 lines
1.4 KiB
AL
49 lines
1.4 KiB
AL
codeunit 50400 "Test UI Handler Capture Good"
|
|
{
|
|
Subtype = Test;
|
|
|
|
[Test]
|
|
[HandlerFunctions('CustomerCardHandler')]
|
|
procedure CustomerCardShowsSelectedCustomer()
|
|
var
|
|
Customer: Record Customer;
|
|
begin
|
|
LibrarySales.CreateCustomer(Customer);
|
|
CapturedCustomerNo := '';
|
|
|
|
Page.RunModal(Page::"Customer Card", Customer);
|
|
|
|
Assert.AreEqual(Customer."No.", CapturedCustomerNo, 'The customer card opened for the wrong customer.');
|
|
end;
|
|
|
|
[Test]
|
|
[HandlerFunctions('CustomerCardHandler,CreditLimitNotificationHandler')]
|
|
procedure CustomerCardOpensForCustomerWithinCreditLimit()
|
|
var
|
|
Customer: Record Customer;
|
|
begin
|
|
LibrarySales.CreateCustomer(Customer);
|
|
CapturedCustomerNo := '';
|
|
|
|
Page.RunModal(Page::"Customer Card", Customer);
|
|
|
|
Assert.AreEqual(Customer."No.", CapturedCustomerNo, 'The customer card opened for the wrong customer.');
|
|
end;
|
|
|
|
[ModalPageHandler]
|
|
procedure CustomerCardHandler(var CustomerCard: TestPage "Customer Card")
|
|
begin
|
|
CapturedCustomerNo := CustomerCard."No.".Value();
|
|
end;
|
|
|
|
[SendNotificationHandler(true)]
|
|
procedure CreditLimitNotificationHandler(var CreditLimitNotification: Notification): Boolean
|
|
begin
|
|
exit(true);
|
|
end;
|
|
|
|
var
|
|
Assert: Codeunit "Library Assert";
|
|
LibrarySales: Codeunit "Library - Sales";
|
|
CapturedCustomerNo: Code[20];
|
|
}
|