Help on how to handle errors/popups?

Best practices, code snippets for common functionality, examples, and guidelines.
Adutra
Posts: 4
Joined: Tue Apr 26, 2016 8:58 pm

Help on how to handle errors/popups?

Post by Adutra » Tue Jun 14, 2016 4:55 pm

Please help...

I need to be able identify an error when it appears (and snag a snapshot, and click a button), but move on with my test when it does NOT appear.

I looked into the "popupwatcher" action and that seems to help with unknown popups at random times and not with errors/popups that would happen after specific events.

My general "test case" would go something like this, that repeats for "each screen". :

1. Open Screen
1.a Error = No, proceed to next step.
1.b Error = Yes - take screenshot, add a "fail" in report results, click OK to prompt. Proceed to Parent test to continue next screen.
2. Modify screen.
2.a Error = No, proceed to next step.
2.b Error = Yes - take screenshot, add a "fail" in report results, click OK to prompt. Proceed to Parent test to continue next screen.
3. Save Screen
3.a Error = No, proceed to next step.
3.b Error = Yes - take screenshot, add a "fail" in report results, click OK to prompt. Proceed to Parent test to continue next screen.


I need to find/create a recording or code module (not very familiar with) to handle this scenario. I also have to make it efficient. I can't have it sit on step 1.a for 3 minutes before it moves on, and I need to make sure it skips over steps 1.b if no error occurs.

Any suggestions or help?

Martin
Posts: 152
Joined: Fri Aug 15, 2014 12:24 pm

Re: Help on how to handle errors/popups?

Post by Martin » Thu Jun 16, 2016 11:52 am

If you know exactly where the error might happen then it is nothing more than just a basic if-else statement.
if (ErrorExists == true)
{
    // Do this
} else {
   // Do that
}
And a bit more reading related to triggering (or skipping) some testcases:

http://www.ranorex.com/forum/how-to-sto ... tml#p24582
http://www.ranorex.com/forum/jump-to-te ... t6078.html


Plus another point of reference would be related to itterations.

Basically you should have a master test case where the itteration logic is stored and if any child test fails next test cases would be skipped and test would continue with the next iteration.

Adutra
Posts: 4
Joined: Tue Apr 26, 2016 8:58 pm

Re: Help on how to handle errors/popups?

Post by Adutra » Thu Jun 16, 2016 8:05 pm

OK, I am able to get this to work, the bad part is, It takes 15 seconds (was a minute, but was able to modify the timeout settings) to check to see if the error appears or not.. Span that over 15 tests, per screen, thats gonna be a huge length of time to get through dozens of screens. This functions, for now.

Is there a smarter way to do this? would the popupwatcher be better? My concern is that after reading posts on there, that popupwatcher runs on its own thread and can't fail a test case (and the proceed to the next case), I'm not sure it can accomplish what we need.


Code: Select all

 
try {
      Report.Log(ReportLevel.Info, "Validation", "(Optional Action)\r\nValidating NotExists on item 'FrmViewErrorTrapper.MangoHasEncounteredAProblem'.", repo.FrmViewErrorTrapper.MangoHasEncounteredAProblemInfo, new RecordItemIndex(5));
   
       if (Validate.NotExists(repo.FrmViewErrorTrapper.MangoHasEncounteredAProblemInfo, Validate.DefaultMessage, false))
                {Delay.Milliseconds(0);}
                else
                	try {
	                	Report.Log(ReportLevel.Info, "Mouse", "(Optional Action)\r\nMouse Left Click item 'FrmViewErrorTrapper.BtnDetail' at 14;5.", repo.FrmViewErrorTrapper.BtnDetailInfo, new RecordItemIndex(6));
		                repo.FrmViewErrorTrapper.BtnDetail.Click(new Location(BtnDetail_Screenshot1, "14;5", BtnDetail_Screenshot1_Options));
		                Delay.Milliseconds(200);

		                Report.Screenshot(ReportLevel.Error, "User", "", repo.FrmViewErrorTrapper.FrmViewErrorTrapper, false, new RecordItemIndex(7));
		                
		                Report.Log(ReportLevel.Info, "Mouse", "(Optional Action)\r\nMouse Left Click item 'FrmViewErrorTrapper.BtnOK' at 10;6.", repo.FrmViewErrorTrapper.BtnOKInfo, new RecordItemIndex(8));
		                repo.FrmViewErrorTrapper.BtnOK.Click(new Location(BtnOK_Screenshot1, "10;6", BtnOK_Screenshot1_Options));
		                Delay.Milliseconds(200);
		                
   catch(Exception ex) { Report.Log(ReportLevel.Info, "Module", "(Optional Action) " + ex.Message, new RecordItemIndex(5)); }



Martin
Posts: 152
Joined: Fri Aug 15, 2014 12:24 pm

Re: Help on how to handle errors/popups?

Post by Martin » Fri Jun 17, 2016 7:57 am

Well if you really know the time you want to spend on waiting for the error to pop up then you should use WaitForExists with timeout.
public void Method()
{
    // 4s timeout
    repo.Master.blaster.objectInfo.WaitForExists(4000);
}
And handle the exception.

Vaughan.Douglas
Posts: 250
Joined: Tue Mar 24, 2015 5:05 pm
Location: Des Moines, Iowa, USA

Re: Help on how to handle errors/popups?

Post by Vaughan.Douglas » Mon Jun 20, 2016 3:16 pm

I frequently use the popup watcher for all sorts of situations like this. Your approach is pretty much what I do, and timing can be an issue because you could end up waiting a long time for the module itself to finish. This also is dependent on how you've got the error behavior setup for the test case.

I usually handle the timing issues by controlling the timeout values in my coded modules. Another approach would be to add extra validation steps in your main thread. Assuming the popup appears and the validation step would fail at the same time, you should be able to reduce you test time.

I'm not sure why Ranorex would sit on step 1.a for three minutes unless you're using a 3 minute time out or you've got a 30 second time out and your repository object is nested under a couple of rooted folders. If I recall, rooted folders will add to an "effective" time out. So if you've got the object under two rooted folders it'll be 30 seconds for the object itself and another 30 seconds for each rooted folder. The easy solution for this would be to pull the object out of those rooted folders.
Doug Vaughan