Ranorex doesn't detect elements, but does on second test run

Ranorex Spy, Recorder, and Studio.
qss.dj
Posts: 1
Joined: Fri Mar 05, 2021 6:59 am

Ranorex doesn't detect elements, but does on second test run

Post by qss.dj » Mon Mar 08, 2021 7:43 am

Hello,

tl;dr: Ranorex fails to find any elements on the first start of the test suite. If I keep the AUT open and restart the test suite, it all works fine suddenly.

OS: Windows 10
Ranorex 9.4.1
Snapshots are attached

We have a new tool and we wanted to start automation of the User Interface. So I recorded a very simple test case that involves starting the AUT, click around, close the AUT. However, after Ranorex starts the AUT, it fails to recognize anything and the test fails. It fails at the root of the repository, the /form element.

But the strange thing is: if I remove the Start/Close AUT steps it works - under ONE condition: Ranorex has attempted to find an element within the app. So manually starting the app beforehand doesn't cut it. To reproduce this, I kept the "Start AUT" and "Click around" steps but disabled "Close AUT". As expected, Ranorex doesn't find anything within the form. For the next run I also disabled "Start AUT", as the app is already running. NOW it works. Then I tried starting our app manually and just like before only run the "Click around" step. That doesn't work!

So it boils down to this: Ranorex has to attempt to find something in the app and then fail at it, so it works NEXT time I start the test suite again (and I haven't closed the AUT process in the meantime).

It seems like Ranorex is doing something to the app (process). Something that only works the next time I start my test code. This also shows in the fact that after attempting (and failing) to find a UI element, after I close the AUT it is still running in the background ("Get-Process MyAut" still lists the application).

Another tool using the (almost) same technology works just fine. Both are Win32 apps with WPF/DevExpress. The difference is that the new app is made with .NET 5 and is compiled into a self-contained assembly (which however shouldn't be the issue as it doesn't work until Ranorex tries to do something with the app. Also, the "raw"/unpacked assembly in the Visual Studio bin/-Folder has the same issue).

I have also tried the following: I created a Visual Studio solution following this guide (https://www.ranorex.com/help/latest/int ... tegration/) which resulted in the exact same behaviour. But when I copied all the references Ranorex-DLLs into my output directory, it changed. On first try, it found a UI element. It took a few seconds more, but it worked. However, I tested something by having the mouse move to a position relative to that UI element, and it seems like EACH time it has to look for that same element again and again, with multiple seconds to find it each time. And after pressing that button, it didn't find any other elements.

I investigated that and found out that while the RXPaths for said element contain some /container elements, I started the Ranorex Spy again and found out that it tracks the element differently now: all /container are now /element. This only happens after Ranorex was active with this VS solution (and also only if all Ranorex DLLs are copied to the assembly folder!)

This, again, confirms that Ranorex seems to be doing something to the app process.

Interestingly, when all the Ranorex DLLs are copied to the assembly folder, I had to reference the x64-DLLs despite my app being compiled as CPU-independent (AnyCPU).

Is this a bug with Ranorex and .NET 5 or is there anything we can do (in the AUT perhaps?) to fix this?

Kind regards

Dominik
Attachments
After 1st run.rxsnp
Snapshot of application after first test run
(144.79 KiB) Downloaded 10 times
Before.rxsnp
Snapshot of application before first test run
(144.78 KiB) Downloaded 11 times

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

Re: Ranorex doesn't detect elements, but does on second test run

Post by odklizec » Fri Apr 09, 2021 11:17 am

Hi,

Is this problem still actual?

I'm afraid, I don't see any meaningful difference between both snapshots. Have you tried to create a snapshot directly from test? Simply add Create Snapshot action 'before' the typically failing action. And take the snapshot of the whole app, not the failing element (this would most probably fail create snapshot too). Thanks.
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