3

What is the hierarchy to use 'find element' by ID, class, or xpath and so on.

Which is preferred over which?

For some elements class is being used - is that recommended?

Improve this question

2 Answers 2

Reset to default
6

My main criteria is readability and maintainability.
Speed has never been as issue for me. There's other parts of the test frameworks I use that have much more significant speed issues.

The basic idea is always 'what will it take to uniquely identify the element' with two principles:

  • Don't over specify the page structure - this will make the selector more robust
  • Don't under specify the element - use enough information to uniquely identify an element

Generally I will always use CSS over XPATH unless there is a specific reason not to.

My order is

  1. ID If it is actually unique this is always the best bet.

  2. Elements and class/name combinations, e.g. input.last_name or input[name='last_name'] or div.home_address input.street

  3. Text on the page. Frequently more subject to change.

  4. Data attributes, e.g. DIV[data-customer='gender'] These can be an alternative to sharing js tags or layout styling.

  5. Relative address (with xpath). This is for the (rare) occasions when I need to identify an elements on a dynamic page with changing content and then select another element relative to that.

As to whether class "is recommended?". It actually brings up a bigger issues as ID, Class and Name are all used by the following groups:

  • developers
  • designers
  • automation engineers

So if the automation group uses a class as part of identifying an element and then a developer or designer changes that class name, the automation breaks and vice-versa. So this is why you need to use the big picture team approach to this to agree on how to work together effectively.

Improve this answer
2
  • 1
    ... and even for dynamic pages, I prefer to fetch a list of elements using some more stable method, and find the one programmatically. Xpath is just too fragile for my taste.
    – Peter M. - stands for Monica
    Commented Jun 6, 2016 at 15:38
  • Yeah Peter relative addressing is the only reason for me to use xpath and even then it's usually when the content is dynamic, say a row in a table that I want to then get related info from another row, who exact layout varies from request to requests or tests to test.
    – Michael Durrant
    Commented Jun 6, 2016 at 17:26
0

It depends on by which locator your element get located, but you should always follow the order following is top priority(fast) to low priority(slow) locator.

  1. ID
  2. Name
  3. Link text
  4. Partial link text
  5. Tag name
  6. Class name
  7. CSS
  8. Xpath
Improve this answer
3
  • CSS and Xpath can use all most if not all of the previous selectors so including them in the list this way doesn't quite work right.
    – Michael Durrant
    Commented Jun 6, 2016 at 20:43
  • 1
    Hi @MichaelDurrant, I have just arranged the selectors in fastest way to locate elements.
    – Jeevan Bhushetty
    Commented Jul 18, 2016 at 8:55
  • Sure but I think you missed my point. "css" and "xpath" are not selectors. Both of them are syntax for locating elements by their id, name, link text, partial links text, tag name and class name identifier, etc. within the DOM. So in one case I will use the CSS ID and in another the CSS name and in another the partial link text using the XPATH syntax. so 1-6 can be either CSS or XPATH syntax. So this mix in of different syntax and element attributes is confusing.
    – Michael Durrant
    Commented Aug 10, 2017 at 19:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.