官术网_书友最值得收藏!

Pillar 3 – handler functions

Goal: Understand what handler functions are and learn how to build and apply them.

In our first test codeunit example, the Message statement results in the display of a message box. Unless we want to wait until a user presses the OK button, this message box stays there forever, halting the full execution of our test run. In order to be able to have a fully automated test run, we need a way to deal with any user interactions, such as a message box, a confirm dialog, a report request page, or a modal page.

For this, handler functions, also known as UI handlers, have been conceived. Handler functions are a special type of function that can only be created in test codeunits, and aim at handling UI interactions that exist in the code under test. Handler functions enable us to fully automate tests without the need of a real user to interact with them. As soon as specific UI interactions occur, and a handler has been provided for it, the platform takes care of calling the handler as a substitute for real user interactions.

Test function handler functions are defined by the FunctionType tag. The currently available values are shown in the following screenshot:

Each handler function addresses a different type of user interaction object and needs different parameters to let it interact adequately with the platform. Let VS Code and the AL extension be your guide in finding the right signature for a handler function. The following screenshot shows you the signature of a MessageHandler when you hover over the function name:

In case of a MessageHandler function, the signature is the text the message box would show to the user. Handing over this text to the MessageHandler enables you to determine if the right message was triggered.

For a listing of the signature of each handler type, go to  https://docs.microsoft.com/en-us/dynamics-nav/how-to--create-handler-functions.

So, to get the Message statement handled automatically in our first test codeunit, we should create a MessageHandler function:

[MessageHandler]
procedure MyMessageHandler(Message: Text[1024])
begin

end;

But this is only half of the job, as this handler needs to be linked to the test that will execute the code calling Message one way or another. The HandlerFunctions tag is used to do this. Each handler function needs to be called in a Test function and must be added to the HandlerFunctions tag as text. If multiple handlers are needed, these will make up a comma separated string:

HandlerFunctions('Handler1[,Handler2,…]')

Let's apply this to MyFirstTestFunction in a new codeunit and run it:

codeunit 60002 MyThirdTestCodeunit
{
Subtype = Test;

[Test]
[HandlerFunctions('MyMessageHandler')]
procedure MyFirstTestFunction()
begin
Message(MyFirstTestFunction);
end;

[MessageHandler]
procedure MyMessageHandler(Message: Text[1024])
begin

end;
}

Instantly, rather than showing a message box first, the resume message of the execution of the whole test codeunit is shown:

Any handler function you add to the HandlerFunctions tag must be called at least one time in the Test function. If the handler is not called upon, because the user interactions it should handle don't happen, an error will be thrown by the platform, saying: The following UI handlers were not executed, listing the handlers not called upon.
主站蜘蛛池模板: 萨嘎县| 章丘市| 西昌市| 丹巴县| 罗田县| 鸡东县| 屯留县| 栾城县| 张掖市| 蕲春县| 米泉市| 化德县| 奈曼旗| 泽库县| 仪征市| 商洛市| 黑河市| 九龙县| 凤翔县| 龙川县| 塔城市| 太湖县| 定陶县| 永德县| 苗栗县| 正镶白旗| 那曲县| 丹东市| 信丰县| 商水县| 唐河县| 黄石市| 邵武市| 宜都市| 屏山县| 贡嘎县| 东源县| 苍南县| 丰台区| 镇坪县| 湘潭县|