Quicker reading of Flex UI components

Technology specific object identification, supported applications, web technologies, and 3rd party controls.
peter92
Posts: 3
Joined: Mon Apr 14, 2014 2:43 pm

Quicker reading of Flex UI components

Post by peter92 » Mon Apr 14, 2014 3:01 pm

Hi,
We are currently using a trial of Ranorex to create a proof of concept test case. Currently, we are having problems with Ranorex's speed at finding items (meaning we are unsure whether or not to continue with it) on our UI (made in flex, running in IE). Our repo items can be found very quickly in our basic login recordings, allowing our test case to pass quickly. However, some test cases seem to take longer to recognise repo items.

The problem occurs like so: Our flex UI loads, variables are read in from Excel and Ranorex continues running our code module. This is where the problem occurs in some test cases, but not all in our test suite. Ranorex will take a long time looking for certain elements (eg. a button) compared to the other test cases we are running. We have tried this on a number of machines of varying spec, and even our fastest that is used for our current test methods has the same problems.

All of our code modules and recordings ensure that turbo mode is running:

Mouse.DefaultMoveTime = 0;
Keyboard.DefaultKeyPressTime = 20;
Delay.SpeedFactor = 0.0;

so when the element is found it will run the rest of the action (ie. press button, enter text, etc) quickly. Is there any way to have the UI element found faster so that we can have the action can run sooner?

Thanks in advance.

mzperix
Posts: 137
Joined: Fri Apr 06, 2012 12:19 pm

Re: Quicker reading of Flex UI components

Post by mzperix » Tue Apr 15, 2014 7:57 am

Hi peter92,

Idea1
Do you run the tests in debug mode? Try to run them without attached debugger (Ctrl+F5), or from command line, or from the Test Suite Runner. Our scripts got notably faster if we used this technique.

Idea2
Make sure that the button's xpath is unique. We had problems with some buttons, that did not have unique enough xpath. This occured mostly with buttons that tends to get reused (like Submit or Cancel button) throughout the application. Try to run to the point when the button gets a long time to find, stop the script and look in the Spy the referenced button's Xpath.

Best regards,
Zoltán

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

Re: Quicker reading of Flex UI components

Post by krstcs » Tue Apr 15, 2014 1:35 pm

I would agree with Zoltan's second point. Make sure that ALL parts of the XPath are unique.

Try not to use generic paths like: "div/div/input[@name='someName']". Make sure each of the div elements (in this example) have identifying attributes, if possible, like this: "div[@class='someClass1']/div[@name='aRandomDiv']/input[@name='someName']".

In the first example, Ranorex will search for the first div it finds, then it will search inside that div for another div. If it finds one, it will then search for the input element with the given name. IF IT DOESN'T find the input there, it will go to the next div under the top div, and so on, until it finds the input, which takes more time depending on where the input is on the page (in a web site, in this example, it would be similar for any application). Potentially it would need to search every div/div on the page before it found the input.

In the second example, Ranorex will find the first div that has the class = 'someClass1', then it will look for a child div under that that has the name = 'aRandomDiv'. It will finally look inside that div for the input element. This can take much less time depending on the way the application is set up.
Shortcuts usually aren't...

peter92
Posts: 3
Joined: Mon Apr 14, 2014 2:43 pm

Re: Quicker reading of Flex UI components

Post by peter92 » Thu Apr 17, 2014 4:07 pm

That could very well could be the problem. We'll look into this, thanks guys.