Page 1 of 1

Handling dialog and pop up windows

Posted: Mon Mar 12, 2012 4:09 pm
by byonush
I have read through the Handling dialog and pop up windows blog and I am a little or maybe a lot confused. I am very new to programming so please bear with me. When it states that you need to create a seperate thread where is that code suppose to be entered? Currently right now I have my test project and it is broken down into segments. First being that it launches the application and logs in. Second is it runs through a recording called place_trade and it runs through a CSV file that I created from the database with fields mapped to trading symbol, portfolio and strategy. The problem I am having is say we are short on a symbol and my recording clicks the buy button when you place the trade it will pop up with an informational dialog letting you know it changed the trade to a cover. This only requires a simple click of the OK button. There are many other pop ups that may come up as well which I have all the components add to the repository. What I would like to do is if on iteration #2 a message pops up to click ok and just report on which iteration the pop up was on and then continue to the next. If there is more information needed please let me know.

Thank You,
Bryan

Re: Handling dialog and pop up windows

Posted: Mon Mar 12, 2012 4:42 pm
by Ciege
Bryan,
The way you describe your pop ups it sounds like me you need to handle them in the proper execution of your tests. These are not "unexpected" pop ups, rather an expected pop up based on the proper execution of your AUT. In this case you need to predetermine the data that you are going to enter and expect or not expect a pop up to occur, as this is normal execution of your AUT.

An unexpected pop up would be something like an unexpected application exception or similar that you could be looking for.

So again, in your case, you need to write your automated code to expect these popups when they are supposed to occur and not expected them otherwise. If they do pop up when not expected or do not pop up when expected this would be an AUT failure...

Re: Handling dialog and pop up windows

Posted: Mon Mar 12, 2012 6:23 pm
by byonush
Thank you for your response. While these are known pop ups that could occur they do not always show based on a number of different factors. Typically we don't want the pop ups because if we get one it means that something was not entered right and the application generates informational message stating that it cannot do X so it will change it to Y. If I put in the script running to look for who knows how many messages that could generate 1 it would take a long time for each iteration to finish and 2 even though I can put the continue on failure every iteration would fail because either there would be no messages or out of say 10 potential messages it might find one and the iteration would still show as failed because it didn't find any of the other 9. To me this would be an unexpected pop up and because I do not see anything out of the box to add conditional statements like IF or ELSE I am at a loss of what to do.

Re: Handling dialog and pop up windows

Posted: Mon Mar 12, 2012 6:39 pm
by Ciege
If you switch over to writing your own code (as opposed to record and playback) you can surround your code with try/catch blocks that will catch any not found pop up exceptions...
If I put in the script running to look for who knows how many messages that could generate 1 it would take a long time for each iteration to finish
Yes, it will take longer to search for potential windows, but it is the *right* way to test. If you willy-nilly just ignore proper paths in your AUT within your automation test then you are not testing properly and you will miss potential failure cases. You will need to properly account for each and every success/failure path in your AUT else you test will be invalid. Keep in mind with automation, once you have it scripted/coded properly, time is not a factor as you can run these scripts off hours when no one is around or on extra test machines that would not be used otherwise and testing time would be a non issue.


Pseudo code below is one example of a possible solution...

MyTextEnterMethod(ranorex.text TextBox, string TextToEnter)
try
{
Test TextToEnter to see if I should get a popup - TFShouldGetPopup
Enter text in text box
Click Ok
try
{
check for pop up
if TFShouldGetPopup = true
close popup
if TFShouldGetPopup = false
close popup and return an error
}
catch (ranorex exception e1)
{
if e1 = not found exception and TFShouldGetPopup = false do nothing
if e1 = not found exception and TFShouldGetPopup = true return failure
if e1 = any other exception, report it and return failure
}
return success
}
catch (ranorex exception e)
{
report e and return failure
}