Configure Spy to give detailed XPath (trying to avoid "//")

Ask general questions here.
Posts: 30
Joined: Fri Jun 07, 2013 11:07 pm

Configure Spy to give detailed XPath (trying to avoid "//")

Post by sergii » Thu May 29, 2014 5:41 pm

Do you aware of the way to let Spy to take more time and return more detailed XPath?

Sometimes for 30+ level of deepness of elements, Spy is returning relatively detailed XPath in 2-3 seconds, but sometimes just after second it shows e.g. /dom/body//div//flex//container//form//text[@id='txt'] - which is really bad, as during execution it takes 3 seconds to find where to click.

In contrast with XPath like: /dom/body/div/div/div/div/flex/container/element/container/container/element/container/form/
Which always works in less than 0.5 second during execution.

How to set up Spy to always take whatever time needed to find detailed and good Xpath, but not just throw 20% of path with bunch of "//" instead of actual elements?

Posts: 30
Joined: Fri Jun 07, 2013 11:07 pm

Re: Configure Spy to give detailed XPath (trying to avoid "//")

Post by sergii » Thu May 29, 2014 5:50 pm

After switching "generation mode" config to "Reduce" I got instead of "//" actual elements with item number
e.g. element[8] - that is obviously going to be different next time page will be generated with other content.

In "Simple" mode Xpath is becoming really unreadable with 100 characters of description per each element, so whole XPath for 30 deepness is half of page long :(

Posts: 2683
Joined: Tue Feb 07, 2012 4:14 pm
Location: Austin, Texas, USA

Re: Configure Spy to give detailed XPath (trying to avoid "//")

Post by krstcs » Thu May 29, 2014 6:05 pm

Have you tried using the Unique ID operator in the xpath? Where you have an object that has an id attribute, if it is unique to that element, you can use the xpath like this:

Code: Select all

It is much faster than navigating the whole path, which is what you are asking.

I would also suggest that putting all of the parents in the path might not get you as big of a performance gain as you think. If you have generic (as in no attributes) path elements, Ranorex still has to search the parent element for all elements matching that generic to find the first one that matches the WHOLE path following. If there are several paths before the intended one that match to just 3 or four levels, the time to id will get larger as it searches through each path branch.

From my experience, I'm not sure I could really complain about 3 seconds versus 0.5 seconds for an automated test on a web page where loading the page (and thus waiting for it to finish) can take anywhere from 5-20 seconds, under good conditions.

Is the extra 2.5 seconds causing a problem for you? Is it causing other timing issues? Are you going to be sitting and watching each test? Is the test running on your system, and therefore keeping you from other work?
Shortcuts usually aren't...

Posts: 30
Joined: Fri Jun 07, 2013 11:07 pm

Re: Configure Spy to give detailed XPath (trying to avoid "//")

Post by sergii » Mon Jun 02, 2014 7:49 pm

Just tried to use /dom//button[@id='_Patient_Button5']
Spy returned result in 12 second. During the script execution button was found in 9 seconds and second time in the same script - 2 seconds.

Alternatively I have used this:
Spy returned result in 0.7 seconds and during script execution each time not more than 600ms used to click the button.

I cannot agree that "//" is in any way faster for flex applications, especially at high level. It's at least 15 times slower. "//" in the end of the path is not so "expensive", because less part of the DOM tree need to be inspected.

All data is real in real world application. I agree, however, that path "/dom/div/div/div/div/div/button" is not better than "/dom//button", but luckily it's not the case in my application.

As for the 2.5 seconds. I have more than 200 elements in Repository and extra 2.5 seconds for each one makes the whole test suite 10 minutes longer.
Yes, in Agile/Scrum approach we are running partial regression tests after every major commit from Dev team (3-4 times per day for about 1 hour). Web application is getting loaded one time so 5-20 seconds delay happens once, while bad ranoreXPath is giving extra 40 minutes of test execution (25 test cases 3-4 times per day).