Need For Speed: Storing objects and working with them

Technology specific object identification, supported applications, web technologies, and 3rd party controls.
User avatar
testautomator
Posts: 67
Joined: Fri Oct 25, 2013 6:37 am
Location: Bangalore, India

Need For Speed: Storing objects and working with them

Post by testautomator » Wed Aug 27, 2014 12:14 pm

Hi,
Our project was little slow in identifying objects and working with them. We have xpaths and dont use Rx's object repository at all. All our objects are in an XML as xpaths.
Now we have methods to retrieve an object's xpath and search for that object in the application. This was taking time. So what we did?
Now we have a parent for all the objects. For example there are some objects under a container. This container becomes parent for these objects. We store this parent for future reference and keep looking for objects underneath it. This improved speed a lot since we dont look for these objects from the top every time.
We took it to next level, we stored the objects as well. This improved the speed even more.

Then came the problems. Rx was faster than our application. It started clicking on objects which are present in the dom but not yet drawn on the screen! We dont know how that happens but it happens. Sometimes the objects might have changed the states and the stored ones are not reflecting their new state.
So what we did? We put a refresh clause to search the objects from the top and get the latest object. This has solved a lot of our problems. But there is one unique problem around which we are not able to wrap our heads around it.
Here it is. The parent which we store is somehow holding on to old objects and our findsingle and tryfinds are failing.
Example:
storedparent.TryFindSingle("button"); // Fails Even though the button is there under the parent when we spy.

Can anyone tell us why the stored parent is holding on to old objects?

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

Re: Need For Speed: Storing objects and working with them

Post by krstcs » Wed Aug 27, 2014 2:50 pm

I would really suggest that you use the Ranorex repository instead of re-inventing the wheel. Ranorex has already implemented everything that you are trying to accomplish with your solution in the repository structure. There is no reason to recreate it, you are just making more work for yourself in the long-run.


As for the timing of things, Ranorex will run as fast as you let it. If you need it to wait for something, then you need to put wait actions into your tests. The recommended solution is to use a Validate Exists action on the last element of the page that is being loaded and then do your clicks or other actions. You could also use a Wait For Exists action as well. It will wait up to the time limit you give it for the element to exist.

One thing I do is add " and state='complete'" to my top-level webdocument's path, such as: "/dom[@domain='www.mydomain.com" and state='complete']". This will force Ranorex to wait for the whole page to be in the complete state before it attempts to do anything to it.
Shortcuts usually aren't...

User avatar
testautomator
Posts: 67
Joined: Fri Oct 25, 2013 6:37 am
Location: Bangalore, India

Re: Need For Speed: Storing objects and working with them

Post by testautomator » Thu Aug 28, 2014 5:50 am

Hi krstcs,
Thanks for the reply. Let me try those suggestions today.
One more problem we are seeing is that Exists comes out as true but working on it errors out. We think that UI is slower than the doms structure. Because we are storing the parent and Rx is just waiting for the element in the path to come up since it does not have to travel all way from the top. Meaning, Rx finds it before it is drawn on the UI and errors out. Is it possible?
We are too deep into this xml with xpaths :( I am afraid we have no choice on that. We did it because we thought it would be independent of the Rx repository and easy for us to maintain the repository by just changing the xpaths. Also, internally Rx does update the xpaths. But disadvantage is the problem that comes without the repository ;)

Anyway, let me try that out
Last edited by testautomator on Thu Aug 28, 2014 7:03 am, edited 1 time in total.

User avatar
testautomator
Posts: 67
Joined: Fri Oct 25, 2013 6:37 am
Location: Bangalore, India

Re: Need For Speed: Storing objects and working with them

Post by testautomator » Thu Aug 28, 2014 6:52 am

I also have one more question. We are trying to see if we can use the object is valid or not property but it is giving erroneous output. Saying the object is valid and when we try working on it Rx throws an error.
Why and how?

User avatar
Support Team
Site Admin
Site Admin
Posts: 11709
Joined: Fri Jul 07, 2006 4:30 pm
Location: Graz, Austria

Re: Need For Speed: Storing objects and working with them

Post by Support Team » Fri Aug 29, 2014 1:14 pm

Hello testautomator,

As already mentioned by krstcs, it’s often necessary to validate objects, add delays, wait for specific objects and so forth in order to avoid timing issues.

In order to analyze the issue for your specific object we would need more information about your application under test as well as the test itself.

May I ask you to create a Ranorex snapshot of your application under test? Additionally, please describe on the base of the snapshot, how your test should look like.

Thank you in advance.

Regards,
Robert
.
Image

User avatar
testautomator
Posts: 67
Joined: Fri Oct 25, 2013 6:37 am
Location: Bangalore, India

Re: Need For Speed: Storing objects and working with them

Post by testautomator » Tue Sep 02, 2014 8:05 am

Hi Robert,
We are doing all the necessary object waits but sometimes the Rx finds out that object is visible and tries to work on it. Then it fails since object is still not yet appeared on the screen! I know its strange.
Anyway, is there a way where we can say that object can be verified for validity or state like we have for DOM(dom.sate)?

Anyway, we are preparing our project so that we contact you guys. We are just finalizing the access issues for our application to Rx.