UnexpectedDialogAction.HandleAndFailTest handles but doesn't fail test

[Claus]

If we set UnexpectedDialogAction.HandleAndFailTest in our settings and trigger an alert, such as:

ActiveBrowser.NavigateTo("http://www.w3schools.com/JS/tryit.asp?filename=tryjs_alert");
ActiveBrowser.Frames["view"].RefreshDomTree();
ActiveBrowser.Frames["view"].Find.ByExpression<HtmlInputButton>("value=Show alert box", "tagname=input").Click();

Then the popup (which I assume is considered an unexpected dialog) is automatically handled, but the test passes. Same behavior seen in IE and FF, using Telerik Testing Framework build from December 29 2011.

Is this correct behavior? We'd really like unexpected alerts to fail our tests.

Kind regards
Saxo Bank A/S

Claus Topholt

[Anthony]

Hello Claus,

Unfortunately the Framework treats HandleAndFailTest and HandleAndContinue the same way. This is because there is no "test" to fail in this context.

There is a work-around that requires a real simulated mouse click and an additional step after the dialog. The caveat is that the browser remains open after the failure, however, but the correct error is reported.

Manager.Settings.UnexpectedDialogAction = UnexpectedDialogAction.HandleAndFailTest;
Manager.LaunchNewBrowser();

ActiveBrowser.NavigateTo("http://www.w3schools.com/js/tryit.asp?filename=tryjs_alert");

ActiveBrowser.Frames["view"].RefreshDomTree();
ActiveBrowser.Frames["view"].Find.ByExpression<HtmlInputButton>("value=Show alert box", "tagname=input").MouseClick();

ActiveBrowser.NavigateTo("http://bing.com");

Greetings,
Anthony
the Telerik team

Check out Telerik Trainer, the state of the art learning tool for Telerik products.

[Claus]

Hi Anthony and thanks for your reply!

Unfortunately we can't use a simulated mouse click, since we need the tests to run scheduled every hour on a locked computer. We're big on continuous integration/delivery and so have a very automated environment.

We had actually already discovered the workaround you suggest, and I was about to report the browser-not-closing as a bug :-) The settings.Web.KillBrowserProcessOnClose property can kill off IE in that scenario, but not FF. And it still requires a simulated real simulated mouse click, which is not an option for us.

Kind regards
Saxo Bank A/S

Claus Topholt

[Anthony]

Hello Claus,

Another option is to intentionally handle the dialog, and, if handled, throw your own exception. This of course requires the code to be placed where the dialog could potentially appear:

Manager.LaunchNewBrowser();     

ActiveBrowser.NavigateTo("http://www.w3schools.com/js/tryit.asp?filename=tryjs_alert");

             

AlertDialog ad = AlertDialog.CreateAlertDialog(ActiveBrowser, DialogButton.OK);

Manager.DialogMonitor.Start();

Manager.DialogMonitor.AddDialog(ad);

 

ActiveBrowser.Frames["view"].RefreshDomTree();

ActiveBrowser.Frames["view"].Find.ByExpression<HtmlInputButton>("value=Show alert box", "tagname=input").Click();

 

try

{

    ad.WaitUntilHandled(2500);

    throw new Exception("Failing Alert!");

}

catch (TimeoutException)

{

}

Manager.DialogMonitor.RemoveDialog(ad);

All the best,
Anthony
the Telerik team

Check out Telerik Trainer, the state of the art learning tool for Telerik products.

[Claus]

Hi Anthony,

Thanks for the suggestion! Unfortunately that's not really a solution for us, since we actually want the test to fail in case there is any unexpected alert. Anyway, I just wanted to also comment on something else you said:

"Unfortunately the Framework treats HandleAndFailTest and HandleAndContinue the same way. This is because there is no "test" to fail in this context."

Why is that? Is it because the Framework can't differentiate between the two enums? If an unexpected popup is auto handled, it seems easy for you to slip an Asset.Fail("unexpected popup") into the code just after handling the popup...?

Kind regards
Saxo Bank A/S

Claus Topholt

[Anthony]

Hello Claus,

When using the Unexpected Dialog Action in a standard Test Studio test, a flag is checked after each test step to determine what to do if an unexpected dialog occurs.

There are no "steps" in the Framework, just lines of code, so the above method cannot be implemented. The difficulty is getting the exception from the secondary thread (where the dialog occurs) back to the main thread to fail the "test."

All the best,
Anthony
the Telerik team

Check out Telerik Trainer, the state of the art learning tool for Telerik products.