I’m working on a project that relies heavily on UI automation, but I’m facing an issue where the selectors change across different environments. For example, selectors in the dev environment are different from those in the testing environment. As a result, whenever I move the code between environments, I have to rework all the UI elements, which is quite time-consuming.
One idea I had was to create a selector configuration setup to handle this. I’d love to hear your thoughts—do you think this is a good approach, or is there a better way to manage this?"
Hey @Rahul_Rajendran
Yes, your idea of using a selector configuration setup is a great approach. The recommended way to handle this is by using dynamic selectors, where the variable parts are stored in config files or assets.
This way, you don’t have to rework all UI elements when switching environments - just update the variables.
Using CV to target the elements. As CV works on positioning of elements, it has less or no impact if element internal properties/attributes varies across environments.
Additionally, because you would anyway have to work through selectors for another environment to have the selector configuration set up, i would consider having switch mentioning environment the process is being run on. Define asset for environment and have its values defined as “dev” for dev, “uat” for uat and “prod” for prod. So, according to the environment selected, activities/selectors will get executed. So basically, same activities under different switch cases with different selectors.
Yes, using a selector configuration setup is a good approach. Store environment-specific selector parts in a config file or Orchestrator asset, and dynamically build selectors using variables. Alternatively, use wildcarding, anchor-based selectors, or modern design experience with strict UI descriptors to create more environment-agnostic selectors. This reduces rework and improves maintainability across environments.