Ranorex Forum

Hello Users,

I'm afraid that this might be a dumb question but I'm all new to Ranorex.
Is there a way to execute a recording module depending on which state the software is in?

I want to automate a Software that somehow starts in minimized mode after the Launcher finished, so the first module coming after that will fail (timeout, element not found).
The idea is to maximize the window if minimized (timeout appears).

This might be also helpful in implementing some fallback mechanisms if needed.
All i found so far was conditions depending on a data source value.

Thanks!

Make your very first action be the "Maximize" action on the top level window. It will always maximize the window regardless of the window's current state. It won't fail if the window is already maximized. This way you don't even have to do any logic, Ranorex will just attempt to maximize the window and then move on.

Thank you this seems to do it.
However I'm still curious about how to implement "fallback mechanisms" as I haven't found any documentation yet.
In other words some best practices in making your test scenario more stable.

I was thinking about something like this: if recording x fails -> close data -> start testcase y
This way I assume that maintanability is better (if more than one recording fails it will show me all failed ones after the first run, instead of letting the whole run fail each time a recording fails).
I also assumed that conditions would do this job but they obviously don't.

Or is this a generally wrong approach?

To me, there are a few ways to make it more stable:

1. Break your recordings down into the smallest possible units of work. This will make more recordings, but each one will be easier to maintain. You can then just drag and drop the modules into the test suite/case/folder in the order you need for each case. Maintainability is not about pass/fail, it's about how much time you have to spend fixing/changing the code/modules when changes happen to the AUT.

2. For more stability, make sure your RanoreXPaths are good. They should be as specific as possible, but just generic enough to work in each intended situation.

3. For true fallback, you need to know the point in each test case where you might need to reset and then use teardown/setup sections to handle issues that might arise. There are times when you might need to go into code to handle it, but Ranorex also has failure handling conditions for each test case/smart folder that you can set.


However, I've found that most of the time, keeping your tests as simple as possible and doing #1 and #2 above, your tests will be pretty stable and you won't need to worry about fallback.

A lot of it is trial and error based on your AUT though, so take it for what it's worth. Once you figure out what works for you, keep doing that.