How to get what you expect: Test Handlers
Jalmaraz
667
Like
Share
ReportI did not plan to write about testing so close to my previous post, but it simply happens. I am involved in product development, and as we said, test and product are one. Sometimes we spend more time writing test code than production code. And that gives you a lot of stuff to think about.
And those days I was thinking a lot about message and confirm handlers.
From annoyance to get exactly what you expect
When run test functions, if you raise a message or confirm pop-up, you get an error and the test crashes. To avoid that, you must set in your test function a message or confirm handlers:
[ConfirmHandler]
procedure ConfirmHandler(Question: Text[1024]; var Reply: Boolean);
begin
Reply := true;
end;
And after creating this handler you must declare it before test function to avoid UI unexpected error in execution:
[Test]
[HandlerFunctions('ConfirmHandler')]
procedure TestFunction()
You cannot place it systemically, because if you declare the handler and the function does not use it the test crashes too. So, at the beginning of my test code I feel handlers are an annoyance, a tax to pay to get you a successful test result.
But that is not the right approach. Handlers exist for one reason: test running must go exactly as you expected. So, if you did not expect a message or a confirm, it is very good that the test crash.
Getting the most of handlers: specific handlers
You can declare code just to pass tests or go further to ensure that pop-ups you get are exactly the output you expected. I make a test function that only checks that my procedure returns a specific message. We write first this handler code:
[MessageHandler]
procedure MessageCatalogHandler(MessageText: Text[1024])
var
CatalogMsg: Label 'is registered in City Catalog';
begin
Assert.IsSubstring(MessageText, CatalogMsg);
end;
and declare it before the test procedure:
[Test]
[HandlerFunctions('MessageCatalogHandler')]
procedure GetWarningsFromCatalogConeecting()
begin
//Done
//When
ConectWithCalatog();
//Then
With this you will be sure that:
- Then the test function will raise a message.
- This message will contain “is registered in City Catalog”.
Not only you control that the test ends ok. You control the user outputs are exactly that want, giving an extra value to test code.
The problem of answer yes over and over
Sometimes we forget to hide dialog in the batch process and users are bothered by confirmation pop-ups that avoid them working properly. But we want an initial confirmation before the batch execution. To get that we will write this handler:
[ConfirmHandler]
procedure ConfirmBatchHandler(Question: Text[1024]; var Reply: Boolean);
var
CounterErr: Label 'More than one confirmation pop';
begin
BatchCounter := BatchCounter + 1;
if BatchCounter > 1 then
Error(CounterErr);
Reply := true;
end;
“BatchCounter” is a global variable of Codeunit. We declare the test function with this code:
[Test]
[HandlerFunctions('ConfirmBatchHandler')]
procedure BatchcatalogUpgrade()
begin
//Done
BatchCounter := 0;
//When
CatalogUpgradeBatch();
//Then
This way you ensure that confirmation only pops once despite the number of records processed in batch.
*This post is locked for comments