Solid Recording Modules?

Ranorex Spy, Recorder, and Studio.
eldorado25
Posts: 22
Joined: Tue Aug 06, 2019 4:14 pm

Solid Recording Modules?

Post by eldorado25 » Thu Nov 21, 2019 11:07 am

Hi,

I am just wondering as to how it is possible to achieve more solid Record Modules and what is considered your standard procedure for creating a new one.

My current issue is that the Record Modules are incredibly simple and easy to use, but a lot of the time when playing back a recorded module it will 'miss' elements that I have clicked when recording (by this I mean it will either not find it and give up, or click an element near the one clicked). This issue does not occur when I use code modules to just simply Click() an element.

The screen size has not changed, the zoom has not changed, essentially all factors are the same.

Is it just the case of maybe including more validation and verification factors (like waiting for something to exist, ensure visible and then click) to make it more likely that it will not fail?

Thanks in advance

User avatar
odklizec
Ranorex Guru
Ranorex Guru
Posts: 6157
Joined: Mon Aug 13, 2012 9:54 am
Location: Zilina, Slovakia

Re: Solid Recording Modules?

Post by odklizec » Fri Nov 22, 2019 11:51 am

Hi,

At first, it's impossible to suggest something reliable, without seeing an example of error (in case the element is not found), full xpath of failing repo element and, at very least, Ranorex snapshot of the problematic element(s). Could you please post an example of error (ideally, entire report) and Ranorex snapshot?

At next, recording elements and actions is just the first step! After each recording session, you should review EACH and EVERY recorded element, mainly their recorded xpaths. Each xpath should be checked, if it really returns an unique element. Additionally, you should remove all potentially changing (dynamic) attributes and replace them with something more persistent. Simply put, Racording is just a handy feature, but you should always review and edit its result.

And of course, WaitFor actions should help too. However, it should not be necessary to use WaitFor actions in every recording and for every element. Typically, it should be enough to use WaitFor only once per recording and not even in all recordings. Just in those, which should do something after the UI change or reload.
Pavel Kudrys
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

eldorado25
Posts: 22
Joined: Tue Aug 06, 2019 4:14 pm

Re: Solid Recording Modules?

Post by eldorado25 » Mon Dec 09, 2019 12:50 pm

Thank you for your response!

There are 2 issues

One the application I am working on has a header bar that has the text render on the layer underneath it, so when ranorex tries to click on these, it will instead click on the header bar. This is bad design and my current work around this is to user PerformClick() which is okay.

My second issue is that sometimes it feels as if it 'rushes' to click somewhere, and then will overshoot its target. But if I do the same thing in a code module, it will use click on the element perfectly fine.

I am trying to weigh up the pros and cons of code modules and record modules. I believe I am swaying for using both in my test cases.

User avatar
odklizec
Ranorex Guru
Ranorex Guru
Posts: 6157
Joined: Mon Aug 13, 2012 9:54 am
Location: Zilina, Slovakia

Re: Solid Recording Modules?

Post by odklizec » Mon Dec 09, 2019 1:17 pm

Hi,

As for the first issue, it's hard to tell how to fix this problem (other way as PerformClick), without seeing the snapshot of the problematic element and exact xpath you are using now. Could you please create and post the snapshot (NOT screenshot) of the problematic header element? In most cases like this, it should be enough to simply redirect xpath to the parent element and click the parent? But if an action is attached to the underlying element, then yes, PerformClick may be the only solution. Mouse click can click only the top-most UI element. \

As for the second issue, I think I may recognize this Recording module behavior (it happens mainly on VMs). The solution might be enabling Turbo mode for given recording module. This will eliminate mouse 'dragging' to the target position and simply perform click at given position. BTW, please make sou re you are using the most recent Ranorex version! ;)
Pavel Kudrys
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