Solid Recording Modules?

[eldorado25]

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

[odklizec]

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.

[eldorado25]

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.

[odklizec]

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!