Unique identifiers for ui automation

Question

Our ui automation team is asking for a better way to select elements for their automated tests. My thinking is that we can inject a dedicated attribute (say "ui-auto") for each testable element. This attribute would have a value which is:

• unique
• persistent (doesn't change across sessions or page loads so as to not break the tests)
• predictable (follows some naming convention depending on action type, location, etc.)

My questions are:

1. Is this a good idea? better ideas are welcome.
2. Are there existing conventions for this?
3. What the best way to implement this?

I should mention that we are using angular and I thought that using some kind of directive and/or service would help automate this.

I should also say that I don't want to use the "id" attribute b/c I'd like to have separation between development concerns (ids may be used for javascript), and qa concerns (selection of elements for automated tests)

Answer 1

In our implementation we add to the DOM element a data-awt attribute, the value consists of a context (page and mode) type and unique string. As we use the EXTJS library our type is the xtype and the unique string is components name or text property. The context is developer controlled by placing a unique property on the upper most parent and all children use this as their context.

In practice we end up with data-awt values like devicesListing-button-edit, deviceDetails-displayfield-name, deviceDetailsEditWindow-textfield-name.

We found that relying on css, id, or other attributes aren't reliable and predictable since we don't want to rewrite our tests whenever there is some UI change. Now the test only needs updating if an existing element changes its name (for example the PM says the name field should now use the 'customer' data from the DTO).

Answer 2

You can also use the class of the element and provide a unique identifier prefixed with something like "auto_" or "t_".

The agreement exists that if anyone changes the class name with that prefix, tests will break.

@o4ohel I agree that not using ids is better as devs also depend on them and they need to change sometimes. Identifiers for automation should be isolated. It's nice to have that separation.