To Whom It May Concern
I developed my test cases against a previous version of the tested application and now that the application which is a Windows Forms application has been upgraded Ranorex cannot see it when running the test cases. I am using Ranorex 9.0 and have had a look at the Spy and changed the setting of the application heading from the old version to the new version and this did not fix the problem. I also removed and re-added the Run Application task in the test case but unfortunately this did not help either.
Also if this behaviour occurs every time the tested application is upgraded we will need to upgrade the test cases also. Is there a setting in Ranorex that either ignores the version number of the tested application or is there a parser in Ranorex that I can run the test cases through to upgrade them?
Could someone please help me?
yours sincerely
Craig Hoy
After Upgrading Test Application Ranorex Can No Longer See It
Re: After Upgrading Test Application Ranorex Can No Longer See It
Hi,
Unfortunately, from you description is not quite clear what exactly Ranorex cannot see? Do you mean the Spy/Recorder is not able to track the individual element in your app? Or Ranorex just fails to find the elements, based of the xpaths stored in repository? Could you please mention exact Ranorex version and post an example of error you are getting?
In your post, you mentioned you want to ignore the application's version number. My guess is, that Ranorex simply cannot find the elements, due to the fact that xpaths in your repository contain version number and possibly other strings, which are version dependent? In this case, you must simply eliminate such strings and make the xpaths version independent. It's something that must be done manually, ideally, after each single recording session. Ranorex simply picks strings, which he thinks are best for the element identification. However, it does not have any sense of context, so it may also picks strings, like version number or actual user name, which are definitely not good in long run. And this is why you should always check the recorded xpaths and eliminate all potentially changing strings from them.
Could you please post an example of failing xpath (as shown in report) and ideally also the application snapshot (NOT screenshot), so we can evaluate both and eventually suggest sustainable xpath?
Unfortunately, from you description is not quite clear what exactly Ranorex cannot see? Do you mean the Spy/Recorder is not able to track the individual element in your app? Or Ranorex just fails to find the elements, based of the xpaths stored in repository? Could you please mention exact Ranorex version and post an example of error you are getting?
In your post, you mentioned you want to ignore the application's version number. My guess is, that Ranorex simply cannot find the elements, due to the fact that xpaths in your repository contain version number and possibly other strings, which are version dependent? In this case, you must simply eliminate such strings and make the xpaths version independent. It's something that must be done manually, ideally, after each single recording session. Ranorex simply picks strings, which he thinks are best for the element identification. However, it does not have any sense of context, so it may also picks strings, like version number or actual user name, which are definitely not good in long run. And this is why you should always check the recorded xpaths and eliminate all potentially changing strings from them.
Could you please post an example of failing xpath (as shown in report) and ideally also the application snapshot (NOT screenshot), so we can evaluate both and eventually suggest sustainable xpath?
Pavel Kudrys
Ranorex explorer at Descartes Systems
Please add these details to your questions:
Ranorex explorer at Descartes Systems
Please add these details to your questions:
- Ranorex Snapshot. Learn how to create one >here<
- Ranorex xPath of problematic element(s)
- Ranorex version
- OS version
- HW configuration
