When choosing which element locator to use in your automation tests it is important to know which locators are better to use than others.

This will help you cut down on your script maintenance and strengthen your confidence that your tests are actually testing the element you intended to.

We made up this fun little diagram to illustrate what we believe are the tastiest, yummy, and edible locators to use in your automation scripts. An apple tree seemed a good representation along with the statement, “When writing your test automation scripts it’s good practice to go after the low lying fruit rather than reach for those at the top of the canopy.”

The tastiest locators are the low lying fruit on the locator tree of life.

If possible, and if your application developers are following web standards, the best locators to use are unique ID, Name, Class, Link, and Text locators. While IDs, Names, and classes locators are attributes and Links and Text are elements in terms of HTML, for testing purposes they are all very good locators to use to interact with web pages.

Some of the yummy but not tastiest element locators include Index, Xpath, Child Elements and CSS properties. Index and XPath locators are needed sometimes when unique ids, names, classes, text, and links can’t get you the handle you need. The work by narrowing the scope of the search for the element on a page. So if an element exists with the same ID as another element on the page but is in a different division of the page, you can narrow your search to that division and then search for the id you want because it will be unique in that scope. The Index locator is great for getting hold of tables and elements within tables. These can be good ways to get at an element if tastier options do not exist but tends to be a pain to script.

But for now, here is an example of an Awetest method we wrote to get the index of a row in a table using the text locator.

  def get_index_of_row_with_text(table, strg)
    msg &lt;&lt; "row in table :id=#{table.id} with text '#{strg}'"
    index = nil
    table.rows.each do |row|
      index      += 1
      if row.text =~ /#{strg}/
        break
      end
    end
    index
end

def get_index_of_row_with_text(table, strg)

msg << "row in table :id=#{table.id} with text '#{strg}'"

index = nil

table.rows.each do |row|

index += 1

if row.text =~ /#{strg}/

break

end

index

end

/html/body/div[1]/div[5]/div/table/tbody/tr/td/p/a[3] (An example bad XPath – it will break as soon as the page layout changes a bit) Example from Jodie Miners

Narrowing your scope to the Child element using methods like selenium’s findElement() and findElements() methods is another way access elements on a page but, like index and XPath locators, it can be a pain to script.

CSS properties can also be used as locators to gain access to page elements and there is a great cheat sheet for XPath and CSS elements here and a nifty article on Reading CSS properties using Watir-WebDriver here.

The last category of element locators we’d like to propose is the edible category. These locators can certainly get access to the element you are after but in most cases should only be used in a last resort if all other options have been exhausted. You can think of these as ripening apples. They might still be green and little bitter but if you are starving you might as well eat them!!

These include Javascript Events, DOM Elements, Keystrokes, and page coordinates. Sometime you might need to fire off some JS Events like drag and drop or mouse up or down. In this case, the only way to test the functionality of the JS is to fire off the events. There is no other way around it.

Some of the useful commands are:

Click and ClickAt
MouseDown and MouseDownAt
MouseUp and MouseUpAt
MouseMove and MouseMoveAt
DragDrop (useful for moving slider bars that calls a JavaScript event to change a value when the slider is moved). Example from Jodie Miners

If you need to get an element directly from the DOM you can usually get at in in this fashion.

document.forms[0].elements[0]
document.forms['loginForm'].elements['username']
document.forms['loginForm'].username
document.getElementById('username')

document.forms[0].elements[0]

document.forms['loginForm'].elements['username']

document.forms['loginForm'].username

document.getElementById('username')

Keystrokes can be useful in those rare, but becoming less rare, cases where the is some JS on a page that refreshes the page or form upon each keystroke. Think about Google’s auto-complete function in it’s search form.

In the absolutely worst case scenario you could use a ClickAt event with X,Y Coordinates from the top left hand corner of the page but good luck with cross browser testing and window size.

Tastiest Locators

ID
Name
Class
Link
Text or Partial T/ext/

Yummy Locators

Index
XPath
Child Elements
CSS Properties

Edible Locators

JS Events
DOM Elements
KeyStrokes
Coordinates

Blog

Best Practices for Watir and Selenium Locators – The Locator Tree of Life

When choosing which element locator to use in your automation tests it is important to know which locators are better to use than others.

The tastiest locators are the low lying fruit on the locator tree of life.

But for now, here is an example of an Awetest method we wrote to get the index of a row in a table using the text locator.

Some of the useful commands are:

Tastiest Locators

ID

Name

Class

Link

Text or Partial T/ext/

Yummy Locators

Index

XPath

Child Elements

CSS Properties

Edible Locators

JS Events

DOM Elements

KeyStrokes

Coordinates

Sound Interesting?