Best practice: How would you deal with a UI which is to be automated and has lots of unique identifiers?

🙋 Questions
,
1

Given the situation where a UI front-end has lots of unique identifiers (say 100).
Now you’re building a new automation code base and you’ve got to maintain page objects. Would you really work by copy/pasting each identifier into your code?
Is there a best practice I’m missing here? Maybe something along the lines of some shared file that contains unique identifiers which is referenced by front-end people and UI automation people alike?

2

In that scenario I would prob create a script to grab the identifiers and then output them in the required format.

2 Likes
3

@hananurrehman
Sounds like you need to utilise a Page Object Model approach.

We do this now with Playwright, it is as simple as it states, a file with all the page objects, you then give them a ‘friendly reference’ to then use within the code methods to test the features and functionality. If any element then changes, update the POM file as opposed to all the tests.

Yes - this is a ‘Hump of Pain’ - but saves a lot of time moving forwards.

There are tools out there to extract and format the element for various tools, take a look.

Enjoy

1 Like
4

On a related note, however you map the identifiers in code, you could also look at minimizing the # of unique identifiers on a page/view/widget/etc.

As an example, can a group of common elements be abstracted to a pattern with some value that varies? HTML element attributes, element text, or index value. You can then define identifier template with the pattern, and in test script / at test execution time, pass in the the variable value of the pattern to run to render the true value of the actual element identifier (it’s not hard coded in code). This can reduce the actual # of locators you have to manage.

But this method only works when there is commonalities of patterns you can refactor for, and requires a certain degree of skill with XPath and CSS in order to implement, because they can only be done with those two identification techniques, primarily XPath. You might be trading off some execution speed for reduced boilerplate code (of redundant identifier patterns).

1 Like
5

what, just what, if you could get the developers to create a shadow DOM and have all the identifiers in the shadow DOM. Then all that your tests need to do is print the shadow dom identifiers out to CSV while navigating the product, and viola you have all your ID’s all up to date in a format you might be able to consume/ingest into a test framework that can perhaps support “dynamic” discovery of identifiers for you. That’s a grand idea, dynamic identifier discovery using runtime element discovery using a constrained list and some rules?

1 Like
6

You can put all those unique identifiers into a dataset and use regular expressions to call the names of the identifiers in the test script to retrieve their values. That way it is effortless to maintain and easy to use with the feature “dynamic identifier” in the free TestArchitect automation tool.