A Meta Reason for Locator Ids

Sometimes we ask for something, without really understanding what that means. Asking for collaboration opens more options.

This post is an encouragement to ’think around’ some of the advice and opinions that you read online about Automating.

Since this post is an encouragement to ’think around’ then hopefully, if you read it, you will ’think around’ this post and see how it applies to topics beyond Automating.

Add Id’s to Elements

The most common advice I see online for making web applications easier to automate is “Add id’s to the elements on the page”.

I have added “id’s to elements on the page”, so I could say that I have followed this advice.

But I didn’t.

Meta-Advice

I followed the meta-advice:

“Make elements on the page easy to locate and synchronise on”
“Make any additions to the application for non-user activities easy to maintain and add little risk”

But IDs…

Id’s can make it easy to locate elements.

What are the risks?

Id’s need to be unique on a page, or the page no longer validates

This can make page layout tricky, particularly if a group of elements are templated and can appear multiple times, in different places, on the same page.

We might have to affix a unique identifier to the elements. And if it is a group of elements we might need to use parent Id’s as the prefix for other elements e.g.

<div id="emailsignup1">
    <input id="emailsignup1-email" type="email"
         name="mail" placeholder="enter your email here"/>

And, what if the element you want to locate is a list item? To add an id to each element in the list, we would have to affix a unique identifier to the id e.g.

<li id="todo1">Todo 1</li>
<li id="todo2">Todo 2</li>

But what if the list had JavaScript functionality that allowed the user to re-order them, then if we were automating, there is a risk that we would use the id postfix to represent the position, but it might not be.

What other risks?

In some frameworks this might also require significant development effort.
In some applications the list might be populated dynamically as well as from server side so we would have to replicate id generation on frontend and backend.
If a list is dynamic would we have to maintain a ‘count’ or increment from the largest current prefix.
Perhaps Id’s are already being used in the app for CSS styling, and using them to support automating restricts the front end team’s ability to change the front end quickly and switch between styles for A/B testing.

We could no doubt identify far more risks.

Id’s may not always be the best choice.

What is the best choice?

The best choice is an implementation decision and depends on the application, the technology, the team, and the timescales (to name a few attributes).

The best choice is an implementation decision that depends on the development team context.

The best choice is the one made in agreement with the team.

Agreement in the team is best made when the team understand the reasons for requiring the addition. e.g. is it location? is it synchronisation?

One thing that I’ve learned when ‘asking’ for something from other teams or team members is to be clear on the why?: what do I need to do? what is currently stopping me? how will I use this?

Rather than specifying an implementation, specify the requirements.

Discuss the requirements to gain an understanding.

Discuss the implementation options to see what meets the requirements, requires less effort and introduces less risk.

What else could we do?

If we were to discuss the requirement about: making the elements easier to locate.

Perhaps some options are:

training on how to create effective CSS locators, or XPath locators
adding classes to high level surrounding div elements and using relative locators
adding classes to elements and using findElements and performing more processing in abstraction layers in the test code