Suggestion: check that MessageHandler and ConfirmHandler method contain code that checks at least the content vor the Msg/Qst parameter

[lvanvugt]

Quite often I find in test codeunit UI Handlers (Message and Confirm) that do not contain any code. IMHO it should always check the Msg/Qst parameter to validate that the right message/confirm was triggered. If not, it would just handle any message popping up in the execution of the test code.

Justification

When the triggered production code has been changed due to a newly added Message of Confirm, or a change in the flow, existing tests should fail telling me that indeed the business logic has changed. As such it will urge me to update my test code.

Curious what you think about this.

[Arthurvdv]

This can be a interesting path to explore!

Our DevOps pipelines for Test-App's doesn't apply any of the CodeCops, where it could be opportune to have a CodeCop focused on Test-App code, like the example you're referencing on.

In the template for a new Test-App I've added an example codeunit with these there methods included as a starting point. It doesn't prohibit the developer from remove the code from these methodes, but this approach seems te help steering in the right direction.

Let's talk next week together with @StefanMaron to discuss the possibilities here.

[ConfirmHandler]
procedure ConfirmHandler(Question: Text[1024]; var Reply: Boolean);
begin
    LibraryDialogHandler.HandleConfirm(Question, Reply);
end;

[MessageHandler]
procedure MessageHandler(Message: Text[1024]);
begin
    LibraryDialogHandler.HandleMessage(Message);
end;

[StrMenuHandler]
procedure StrMenuHandler(Options: Text[1024]; var Choice: Integer; Instruction: Text[1024]);
begin
    LibraryDialogHandler.HandleStrMenu(Options, Choice, Instruction);
end;