My best guess is to use relative locators, a feature of Selenium 4.
The first toggle button would be found like the button below the assigned label.
The second toggle button would be found like the button below the first toggle button.
Etc.
I am assuming you are talking about this bit being dynamic, well it has to be, since it’s unique, and although I use selenium 3 only, in python for a small project I already hit this issue, and solved it by building my locator at runtime using a function to build the locator string, which takes an id as a parameter and merely builds it. This is the code I write to handle a button, but in your case, you also need a relative locator it seems. I’m not on selenium 4, but have found that writing XPATH relative locators manually is stable, but takes a few attempts. Looking forward to this being quicker myself.
# server_id is a guid
def get_launch_button_by_id(self, server_id):
self.log(f"Find launch button for server {server_id}")
connect_item = 'connect-item'
locator = Locator(By.ID, f"ppr-action-{connect_item}-id-{server_id}")
server_button = self.wait_visible(locator)
return server_button
In here we are subbing two variables into the locator and returning the element from a function. An earlier version of this function actually generalized the ‘connect-item’ constant string here, but we left the variable in for documentation only and make it obvious when the button state is not in “connectable” or ready and enabled mode where that part of the generated ID will change.
This works, because in reality, under the hood, the java rendering code is actually doing exactly the same thing when it runtime generates the HTML we are seeing. I’m a huge fan of talking to your developers and understanding the web or other toolstacks they use. And thus learning about easy ways to check what we need to only.
I interpreted this more as a testability challenge.
I would ask the designers/developers why the id must be dynamic. If it doesn’t have to be dynamic, ask to have the id assigned a constant value. Then, locating the element is easier and your testability has improved.
Hi devtotest, thank you for your response. Since I am new to automation, I was actually hesitant to ask the devs to make the id constant for the sake of automation. But your comment indeed motivated me. I will discuss with the team.
I understand the hesitation and I applaud your effort.
I believe you are not alone with the hesitation as tester/developer collaboration has a wide spectrum of responses. In my opinion, quality is a team effort and requires establishing and maintaining good relationships within the project team.
While this change improves testability for you, I believe it can also improve testability for the developers (I assume they have unit tests!). This change could also help locate elements should they require troubleshooting. There is a win-win for the team in there somewhere!
There are two other things to take into account: identification and accessibility.
Conrad Braam already noticed that the code is automatically generated. There is maybe a small chance that the developers can assign an unique id attribute to every button.
There is a big chance that the toggle buttons are not accessible. This means that disabled users cannot use the web site in a proper way.
People with bad sight use a screen reader. This program reads the state of the button aloud. The shown toggle button tend to have no state which can be detected by the screen reader.
People with cognitive problems might not understand what the state of the toggle button is with the switch to the left.
In several countries there are laws which protect disabled users. Last year I wrote a blog post about accessibility and laws:
