Ranorex Forum

Hello everyone,

We have an AUT with a lot of unexpected elements and we use a popup watcher object to handle them. We use only one PopupWatcher object with Watch() method for each unexpected element.
I would like to know how many Watch() methods can be used for a single PopupWatcher object or at least which is the recommended number. Is there any significant performance impact?
Another question, which is the best approach - a single PopupWatcher object with all the Watch() methods or a number of PopupWatcher objects, each with only one Watch() method attached?

Thank you!

I use individual PopupWatchers, each with only 1 Watch(). But I only have 4. I don't think there is a maximum, but if you use a significant number then you will likely see a slowdown as each one will start it's own thread if you use multiple watchers with their own Watch() methods.

I would recommend that you use PopupWatchers sparingly. There are a couple of issues with them that make them less than ideal for many situations. The biggest is that they run in a separate thread from the main test and cannot interact with or control the flow of the main thread except to throw an exception (the Ranorex mechanism for raising a test error/failure).


In terms of actual test philosophy, we should normally not have any popups that are unexpected, except possibly those that are environmental (network issues, etc.), and even those should be minimized by making sure the environment is well controlled. The actual test flow should account for the possibility of a popup at those points. We should know going into the test scenario that the scenario will or won't cause a popup at a given point. Anything other than that means that we don't have clear and well-defined test cases, which means we may not have fully understood and accounted for all possible test paths.

Thank you for your reply!

Yes, I know that there are a lot of concurrency issues related to the use of Popup Watchers. But, in our case, I think this is one of the best solution we have.

Unfortunately, all the assumptions you have made related to the test environment and test cases are correct. We are dealing with the following situation:

- AUT is a web app consisting in two parts: admin and front end. We DON"T have access to the admin module, tests are covering only the front end. From the admin module, different controls/widgets can be activated/deactivated for the front end and other team is doing this continuously without noticing us. In fact there are several teams using the same environment and altering the app configs in the admin module. Thus, all we can do is to try to manage these widgets, if they appear or not;
- test cases are high level scenarios, most of them bad designed. We have to automate and make them work.

As you see, this is something which should not happen in practice, both points are usually blockers for starting an automation project. As a certified test analyst, I strongly stressed out the effectiveness and the risks for implementing automation for this project. But sometimes, we have to deal with this type of projects in real life.
Therefore, we are dealing with a lot of elements which may appear or not and we have to handle them. Using Exists/WaitForExist/etc. ..will increase the test run and it is not an option due to the high number of widgets.

I was in a similar situation like you, where number of developers often changed settings, causing tests to fail due to different settings. The only reasonable solution of the problem is to setup a separate/mirror test automation site, where only you and your automated test can change the settings. Either this, or you need the access to admin part of the site and change the necessary settings before each test. But even then you will never be sure someone did not change something during the test execution No matter how well you prepare your tests for unexpected behaviors (caused by changed settings), your tests will never be reliable enough unless you start them in stable test environment.