This guide explains how to choose stable attributes and structure your repository so your web tests stay reliable across UI updates and browsers.
Ranorex identifies web elements through repository items and their repository paths (a chain of attributes from parent to child).
The stability of your test depends on the stability of the attributes used in that path.
Choose stable attributes
Prefer attributes that represent meaning
Stable attributes usually describe what the element is or does, not how it looks or where it happens to be.
Good candidates include:
- Accessible names (for example, aria-label)
- Visible labels / stable names that don’t change between builds
- data-test / data-testid attributes (if your dev team provides them)
- Element roles and predictable structure (for example, a button inside a specific header/container)
Avoid attributes that change frequently
These attributes are likely to change between sessions, builds, or browsers and can make tests brittle:
Risky candidates include:
- Generated or session-based IDs
- Framework-generated CSS classes (often produced by build steps)
- Index- or position-based paths (for example, “the 3rd button”)
- UI styling-related attributes that can change without functional changes
Handling dynamic identifiers
When automatic handling is enough
In many cases, Ranorex can tolerate moderate attribute changes. If:
- failures are rare, and
- the element is still consistently found; you may not need to change anything.
When you should adjust the repository item
Update your locator strategy when:
- the element is frequently “not found”
- identification differs across browsers
- multiple similar elements match, and the wrong one is selected
- the path includes dynamic attributes (for example, changing IDs)
Tip: The goal isn’t the shortest path, it’s the most stable path.
Repository strategy for stable web tests
Keep repository items intentional
- Create repository items for elements you interact with often.
- Avoid adding “everything” from the DOM, keep items purposeful.
Use a meaningful folder structure
Organize items so maintenance is easy:
- Page → Feature → Component (recommended pattern)
- Or Feature → Page → Component, depending on your project
Keep repository paths readable
Prefer:
- a stable parent container (section, header, dialog, main area)
- plus a stable child element (button/input/link)
This approach reduces ambiguity and makes selectors survive UI rearrangements.
Cross-browser considerations
Some attributes may behave differently per browser (or appear differently in the DOM). Before scaling your suite:
- validate that your repository paths work in all target browsers
- confirm the same element is being matched consistently