Before we discuss using dynamic, XPath, and CSS locators, let's review again the standards for retrieving WebElements from outside the page object classes.

In keeping within the Selenium Page Object Model, locators go in the page object classes, but not in the utility classes, the test classes, or the data files. Users will often try to cut corners and embed the WebElement class's FindBy methods within the test methods themselves, rather than encapsulating the locators in the PO classes.

This is the wrong approach, and leads to maintenance nightmares when locators, text, values, tags, and links change in the application. We only want to have to make a change in one place when a locator changes.

Here is a summary of the best practices for using locators:

• Page object classes store the locators that define the WebElements or MobileElements
• Getter methods can be created in page object classes to return the static name of the WebElement from the calling instance of the class
• Locators should not be stored in data files and passed in as a part of a dataset (although a map file could be created)
• The order of precedence using locators is always id, name, className, tagName, linkText, partialLinkText first, then css next, followed finally by xpath queries
• Store all common element locators in base classes to allow all subclasses with the same elements to inherit them, reducing the number of elements that need to be defined
• Keep the hierarchy of the locators to a minimum, just enough to make them unique (one or two levels)