Upgrading to 5.4.1 has slowed all our tests

[anzacthecat]

We use Specflow in Visual Studio to run our automated tests and reference Ranorex DLLs where we perform identification and manipulation of web elements. Since upgrading from 5.3.2 to 5.4.1 our test times have massively increased, even doubling in some instances. To get the speeds back up we have tried a variety of things including increasing the speedfactor (which is normally set at 20) but the only one that seemed to make a difference was putting in very detailed paths into the repository.

In order to avoid minor formatting changes breaking our tests, we have adopted a policy of including very little of the 'address' of elements, often just identifying the page as a rooted folder (eg. body/div[@id='MyPage']) and then below that just including the id of the item we want (eg .//input[@id='MyInput']). This has worked perfectly up to now and has meant that if the devs add another div into the page structure it doesn't affect us. However when we tried putting in a much more detailed version of address of the item as provided by the spy (eg. /dom[@domain='mydomain]/?/?/div[@id='MyPage']/?/?/form[@id='MainForm']/div[@id='SearchTabStrip']/div[@id='SearchTabStrip-Tab-General']//input[@id='MyInput']) the tests speeded up noticeably.

Please can you advise as to whether this change is deliberate? Do we now have to invest the time to put this level of detail into all our repository items? This is not a trivial job for us and is also much more onerous to maintain than what we have at present. Alternatively if you can suggest any other reason why our tests might suddenly be running so much more slowly, I would be very grateful.

[krstcs]

I'm not sure why there would have been that large of a change from 5.3.2 to 5.4.1, I didn't see anything like that on my side.

A couple of things though:

1. If you are using id's in your XPath, and the id is unique to an element on the page, then you should probably be using the "[#'id']" convention instead of "[@id='id']", because it will be much faster since Ranorex will assume it is unique and can search an indexed element list for the ID instead of having to search the whole tree (which leads to...)

2. Ranorex searches EVERY ELEMENT until it finds the FIRST MATCH for the given RanoreXPath, or until the timeout is hit. In your case, using very generic paths leads to long search times because Ranorex HAS to search each element and all of it's children (and all the children's children) until it finds the FIRST MATCH for the given xpath. This can take a long time. Either fix your paths to be more specific or deal with the wait. Remember you can use as many rooted folders in your repository as needed to make the xpath more specific, which will also make it easier to fix in the future if your developers change the layout.

[anzacthecat]

Thanks for this. We have tried the idea of changing @id = to #id and it has made no difference.

As you will see from my original post, we are aware of the potential benefits of giving more of the path via rooted folders however given the size of our project this is a big job and what I would like to understand is what has changed between versions and whether there is some way of sorting this out other than making massive repository changes.

We ran the same tests using the same repository against the same website before and after upgrading and the difference was huge. I can't find anything in the upgrade documentation that can explain it.

[Support Team]

Hi all,

Just to keep you up-to-date.
We were in contact with anzacthecat about this issue and it seems that observed behavior was not related to Ranorex itself.

Regards,
Markus (S)