The Ranorex Coach helps you stick to best practices when designing your tests and test suites. It does so by giving you short, non-intrusive hints when it detects certain patterns in your project (called triggers).
These hints contain tips on how to improve your tests and can help you avoid issues in the future.
On this page, you’ll learn:
- How the Coach works
- How to enable or disable it (and individual hints)
- Which hints are available and what they mean
Reference: For more best practices in designing your test structure, also take a look at Structure your tests
Enable/disable the Coach
By default, the Coach is enabled, including all hints. You can disable the Coach as a whole or only specific hints. To enable/disable:
- In Ranorex Studio, click Tools and select Options.
- In the Options dialog, under General, click Ranorex Notifications.
- On the main screen, select Ranorex Coach to select or clear all Coach-related notifications.
-
Select or clear the individual notifications you want to receive in Ranorex Studio.
How it works
When the Coach detects a trigger, it displays a hint. The Coach aims to be helpful without being intrusive. This is why:
- It only checks for triggers and displays a hint when you save or close a file.
- It only shows one hint, even if multiple triggers are detected.
- It won‘t show a new hint until you‘ve dismissed an existing one and saved/closed a file again.
Coach hints are displayed as a small popup window in the bottom right of Ranorex Studio, where they‘re least likely to be in the way. You can close them in two ways:
- Always ignore this hint – closes the hint and deactivates this specific trigger for the future.
-
Dismiss – closes the hint, but the trigger remains active. If the same situation occurs again, the hint can be shown once more.
Test suite hints
These hints are related to your test suite structure, including test containers, conditions, data sources, and run configurations.
Complex nested conditions/data source inheritance
Trigger
The test suite contains conditions or data source inheritance that extend over too many test container levels.
What to do
Keep it simple. Use conditions sparingly and avoid combining multiple data sources across deeply nested test container levels.
More information: Best practices for structuring.
Empty test containers in test suite
Trigger
The test suite contains at least one empty test container.
What to do
Fill empty test containers with modules or delete them if they’re no longer needed.
Test case not preceded by setup region or followed by teardown region
Trigger
The test suite contains at least one test case that isn’t wrapped in at least one setup/teardown region.
What to do
Make sure your test cases are wrapped in at least one setup and one teardown region.
More information: The test suite structure
High number of test containers without descriptions
Trigger
Fewer than half of your test containers have descriptions.
What to do
Give test containers clear, meaningful descriptions so that the purpose of each container is easy to understand.
Data connector has a default name
Trigger
At least one data connector still has its default name, e.g. NewConnector.
What to do
Rename data connectors to meaningful names that describe the data they provide.
Not using run configurations
Trigger
You have a test suite with deselected test containers, but only one (typically the default) saved run configuration.
What to do
Create and use run configurations if you regularly run the same test suite with different test containers selected or deselected.
Recording module hints
These hints relate to recording modules, their size, readability, and how actions link to repositories.
Recording module contains no actions
Trigger
At least one recording module contains no actions.
What to do
Fill empty recording modules with actions or delete them if they’re no longer needed.
More than 30 actions in a recording module
Trigger
At least one recording module contains too many actions.
What to do
Keep recording modules focused on a particular task and only include actions that are necessary for it. Consider splitting large recordings into smaller, focused modules.
Mergeable Key sequence actions
Trigger
At least one recording module contains subsequent Key sequence actions that look like they should be merged.
What to do
Merge Key sequence actions that are fragments of a larger string to improve readability and maintainability.
Key sequence action hard to read
Trigger
At least one recording module contains Key sequence actions that contain non-text input.
What to do
Remove unnecessary non-text input or activate Keystroke optimization to make the recorded sequences easier to read and understand.
Disabled actions in recording modules
Trigger
At least one recording module contains disabled actions.
What to do
Unless you’re troubleshooting, activate disabled actions or delete them if they’re no longer needed. Leaving disabled actions in place can make recordings harder to understand.
Action not linked to repository item
Trigger
At least one action isn’t linked to a repository item when it could be.
What to do
Link actions to repository items, even when optional. This centralizes UI information in the repository and makes it easier to adapt to UI changes.
Validation action preceded by Delay instead of WaitFor
Trigger
A fixed Delay action is used before a Validation action to ensure a UI element can be found.
What to do
Use a flexible Wait for action instead of a fixed delay. This improves test stability and performance.
Absolute path in Start application action
Trigger
A Start application action contains an absolute path.
What to do
Use a relative path instead. Relative paths make your tests more portable across different machines and environments.
Network drive path in Start application action
Trigger
A Start application action points to a network drive.
What to do
Use a relative path that points to a local drive. This reduces dependency on network availability and improves test robustness.
Reversed mouse down/up actions
Trigger
At least one recording contains Mouse up/down actions in reverse order.
What to do
Ensure Mouse up/down actions are in the correct order or use a Mouse click action instead.
Mouse wheel action used in recording module
Trigger
At least one recording module contains a Mouse wheel action.
What to do
Keyboard and Mouse actions usually scroll automatically. If this doesn’t work, try an Invoke action with the EnsureVisible or Focus argument. Alternatively, set the Use Ensure Visible property to True on repository items.
More information:
Repository hints
These hints focus on repository items and their configuration.
Search timeout too low or too high
Trigger
At least one repository item has a search timeout below 10 seconds or over 5 minutes.
What to do
Keep the search timeout within this range. In many cases, 30 seconds is a good default value. Very low timeouts can cause flaky tests; very high timeouts can slow down failed test runs.
Variable in rooted folder in the repository
Trigger
At least one rooted folder in your repository contains a variable in its RanoreXPath.
What to do
Avoid variables in rooted folder paths. Keep rooted folders stable and use variables only further down the RanoreXPath.