Unique Locators

Question:

I have a question that came up today in my team about adding individual locator names and IDs for elements. Right now, my app doesn’t have any unique locators for elements - we have to use full xpaths to find elements, and quite frankly, even then, it’s a very unreliable method of finding elements for me.

I would say our app is definitely mid-size, but the volume that’s actively worked on is much smaller. There are some coding standards but I’m not really involved in those discussions. We’re just now entering a discussion though around using StyleCI, which from my very limited knowledge, leads me to assume that the code is pretty inconsistent. I love that, I’m going to recommend that when the topic comes up next week to just start with IDs in the standards, and take it one step at a time, from the beginning.

Is it worth adding unique names and IDs to elements for automated tests, or do these locators tend to reduce ROI because of the maintenance required to make sure automated scripts keep running?

Insights:

When developers are involved in testing from the get-go, they would easily remember to add IDs. One of the problems, I kid you not, is that when there are a lot of objects they run out of ideas to use for IDs. You can use a fallback method that would try to find an object based on different attributes, So, rather than defining one "by" , I prefer having some file, an XML for example, listing all the attributes, and then getting the attributes from that file and iterating throughout. You could even have a screenshot of it, Or you can directly check the items with UI and use API for the functionality if that's a possibility.

Another solution, ask for accessibility tags, that way they have to use unique identifiers, it will help you, and it will help your users.

-- Noemi Ferrera

Question: If they’re generated (?) by a fallback method then is there still a risk for tags changing as other edits are made on a page? A risk that was mentioned from a team member on this was if they’re generated automatically it could impact the tags when new components are added on a page, breaking previously created tests. Does that make sense? How do the risks compare with using the fallback method mentioned above?

Insights:

One never knows when one is going to need accessibility, nobody plans for that. I'm all in for companies that offer opportunities to all potential users.

-- Noemi Ferrera

Question: How would accessibility tags work? Is there still the same risk of tags changing down the road when say new components are added?

Insights:

There could be, that's why I suggest a mix, but accessibility tags are quite unique and related to elements that the user would interact with. They should be descriptive and unique enough for them to differentiate them. And it's very reasonable that anybody asks for them. They are longer than IDs so the Devs don't need to be so creative with them. And we have the added bonus of helping others too.

-- Noemi Ferrera

Insights:

Maybe if part of the name is unique you can use our starts with/contains/ends with option for the locators.

-- Liron Meir Hefetz

Insights:

This question brought back a lot of memories. I would start by asking a couple of questions.

1. How big is your app? If you have a fairly small app, I would go for it and id's for all the elements I'm currently using in my automation suite. If you have a huge app, the discussion changes. It's not fun for anyone to revisit the code and change stuff as it might have downstream effects. So I would suggest to look at all the previous test runs and find the flaky ones that required ID's and start there. Then, on every active development, have the Dev's add the ID's to their app going forward.

2. Do you guys follow an internal coding standards doc? If you do, start from thereby adding the ID's like a requirement for all the elements and establish a naming convention. Ex: submitBtn, usernameField, something like that. Whatever you all agree upon. So that it will also be easy for you to identify the type of element just by looking at the ID.

-- Avinash Mavireddi

Insights:

Having a locator that you can use is so very worth it - yes, it's a pain in the tail to make sure they all are unique, now and going forward. But I would much rather spend time on naming things, rather than have a test fail because an element shifted - and now a new xpath needs found. You may find that your tests are shorter because of this, as well as more accurate.

-- Arlene Andrews