Unexpected Dialog is actually expected

Hi Alan,

I am sorry to hear you are running into this problem. Are you sure that the UnexpectedDialogAction feature was set to DoNotHandle? I'm asking you to confirm this, because the default setting for this feature is HandleAndFailTest. In your case, since you are using a dialog handler step, it should be set to DoNotHandle.
 
Another thing you can try is to remove the dialog handler step and set the UnexpectedDialogAction to HandleAndContinue. This should work if the dialog is considered unexpected.

If you are still unable to make this to work, we'll need to reproduce the issue locally in order to find what is causing it. Please provide us with a copy of your test and access to your application. Also, please provide your failure log and a copy of the DOM at the time of failure. You can export these to file from the failure tab for your test and add them to a .zip archive. If it is not possible to grant us access to your application, please take a Fiddler trace and attach it to a support ticket in a zip file. You can capture a Fiddler trace using FiddlerCap. A Jing video of the behavior may also help us diagnose your issue. Thanks for helping us advise you.

Regards,
Plamen
the Telerik team

Hey Plamen, 

When the first four runs were set to 'DoNotHandle', the popup never went away, and the script continued with the next steps of performing a search, but the script would timeout waiting for the browser to be ready, which it wouldn't get to because the popup was still open.  I'll send in a ticket.

Thanks! 

I have a very similar situation and would be curious as to what the solution was.

Hello Tori,

I had two dialog handlers in one test file.  In the ticket that I logged, Mario from the Telerik team indicated the following as a resolution:

"There is a known limitation on our dialog handler which only manifests in certain applications when more than one of the same type of dialog is present during a single test. The behavior I am seeing strongly indicates this to be the reason for your issue...Move the click and handle steps involved in prompting the dialog [into] a newly created SubTest (test as a step) to bypass the limitation..."

I just removed the second dialog action and handler into a different test and used the Test as Step function to call the secondary test.  It worked perfectly after that.  Note that the action causing the dialog MUST be in the same test as the dialog handler.

Let me know if you need anything further.

Thanks!
Alan

Hi Alan,

Thanks very much for your prompt and detailed response on such an old post. . .I really appreciate the info!  This is great information, and I'll keep it in mind, but it looks like my situation is slightly different.  I like the Telerik products, but I seem to always find myself frustrated with their rather sparse documentation.  I’ll keep digging! 

Thanks again!
Tori

Hi Tori,

Is this the situation you are referring to? We'll get you all fixed up, I guarantee it.

BTW, the problem you're looking to solve there is very unusual. It's impossible for us to document every possible way that Test Studio and our API can be used. The permutations is nearly infinite. We are very regularly adding to and updating our documentation.

Regards,
Cody
Telerik

I appreciate (and continue to need) your help, and I certainly had no intention of invoking a defensive response about Telerik's documentation.  I understand all too well (and deal with the problem every day in my job) that a complex tool can never be documented "enough."  I'm not sure I understand how my situation is atypical, however.  Many sites use hidden elements with dynamic properties that make consistent identification difficult or impossible using the tools in the Test Studio UI. . .which leads to the need for writing code.  I'm definitely not a sharp enough coder to be doing anything complex or unusual! :-)  I'm finding a list of images, clicking on the visible ones, and handling a confirm dialog. . .that's pretty much it.  I'd love to be able to do so in the UI, but I spent weeks in these forums looking for a solution. . .and unfortunately it just isn't possible with the way our application is coded.  I also wish I could share code from our application, but the customer is a government organization, so they are a bit touchy about doing so.

So, I've been a Telerik customer for about six months.  I have a fairly extensive background in scripting (primarily Perl and VBScript), but I'm by no means a hard core developer.  For what it's worth, here's my point of view on the documentation:

1.  It's largely written for two audiences:  a.) people using the tool in a basic manner who generally need only the functionality available in the stand alone UI; and b.) advanced users doing extensive coding (primarily via the Visual Studio plugin).  I've seen the statement repeated over and over in the forums that coding is generally required for true automated testing of complex applications.  The first group needs no code examples because they aren't coding. . .the second tends not to need many examples because they are experienced coders.  That leaves those of us in the middle who have done some coding, but aren't hard core developers, scraping the forums for every snippet of code we can find.

2.  The documentation is very short on examples with code. . .as are the forum posts.  I can't tell you how many times I have found a thread that seems to be asking exactly the same question I have. . .only to get to the end of the thread with no solution and no examples.

3.  The search functionality is not user friendly.  If I search at http://docs.telerik.com/teststudio for "confirmdiaglog," for example, I get an entire page full of links to essentially the same information (the basic API / namespace information). . .not an example in site!  While API information is useful, it's certainly not sufficient by itself.

Anyway, just providing some feedback, so please don't take it personally.  I do QA for a living, so I'm happy to contribute and discuss things you guys are doing to make the product / documentation better for the user community.  Thanks again for your continuing assistance.

Tori

Glad to help out!  For the documentation, we have been able to leverage the forums quite a bit instead of the API documentation.  To address your concern with code, we have submitted numerous private tickets to Telerik so that any code snippets are not publicly viewable.  Understandably there is not a 'one size fits all' solution.

Good luck!
Alan

Hi Tori,

Thank you for your feedback and viewpoint. We appreciate it and will take it into consideration writing documentation in the future.

@Alan, thanks for assisting where you can!

Regards,
Cody
Telerik