Is there a need to set more than one locater for an element, especially if that one locater is already explicitly pointing to the element you need?
I was on the assumption that maybe it works as a pseudo-check where TestProject will attempt to search for the location using all the locaters as provided before attempting their own self-recovery, but that doesnt seem to be the case.
I have an element used in multiple pages where the only difference for the element between the 3 pages is a numeric value that locates the element on the page. I created an element, added in the 3 separated full XPATH that only change the one value each, but automation still couldnt find the element on my page.
Hi @erik.yeow ,
Some websites use html generation frameworks. These frameworks will often create identifiers that change every time the page is loaded. These are known as dynamic element locators and can be pretty tricky to deal with in UI test automation.
When you add more locators by choosing different attributes, you give this element more effective ways to be found on the page.
You can find more information about this scenario here:
If you have any other questions, feel free to ask
Except that, as I mentioned in the OP, it didnt though.
The 3 XPATH listed were the ones I extracted from the Element Locator when checking out the element.(it’s basically the same button function-wise on 3 separate pages, but the XPATH differs I guess is due to the number of elements before the button generates)
I then gave a try in Record Mode(the specific page I was testing was using explicitly the 2nd path) and, as usual, TestProject’s self-repair AI happened again. (which will hilariously suggest the 2nd path as a “fix”)
The only way that it would work, afaik, is if I re-arrange the locators so that the 2nd path is now the 1st. Then, it will work on that specific page, however it will kinda “break” when I access a page that uses, say the 1st path.
Let me check out that link you provided first; maybe Im misunderstanding something here.