How to generate good locators for elements in Web pages?

Question

This site contains many questions that are about finding the right locator expression (XPath, CSS, etc) for an object in WebPage or about troubleshooting problems related in invalid or dynamic locators. For instance: How to find the xpath locator for logout button?.

• How one can find a good locator expression?
• What tools can generate expressions matching a certain element automatically?
• How to troubleshoot such issues when element does not match expression?

Answer 1

For all three parts of your question, I would suggest to apply one of the following approach (considering only web application, as mentioned in question itself):

1. First and the most naive approach is to use the recording feature. What I have read and understood is that record and playback feature provided by tools is only used for the purpose of Demo and selling the product. But what I have experienced is that there is one more good use of this feature i.e. learning how the tool which you are going to use, finds any element on Application Under Test. See, ultimately you are going to use the same tool for testing, and it will be good and efficient approach to use same method/locator as used by tool itself. in addition to it, every tool now-a-days offers this record and playback feature (Selenium IDE plugin for Firefox, Coded UI, Test Studio, Test Complete etc.).

Each application is different and so the features provided provided by each tool e.g. Coded UI doesn't offer XPath while Selenium offers the same. To start with, capture atleast 2 element of each type (like TextBox, Dropdown, Checkbox, RadioButton, Button, Hyperlink, Menu etc.) using the recording feature and then see the pattern. After that you will not be required to use that record feature for same type of elements but wherever you find difficult or time consuming to find a element, again use the recording feature of your tool for that element or page. This can be used for the troubleshooting purpose too.

2. Second approach is little proficient, considering you are aware of the find expressions supported by your tool and know if your application is having Unique IDs, Name etc. You can get this information from your Developers too. Then, directly use those locators to create a unique logic for finding element, most of the time ID alone should work but if not then pair it with different locator like Name, ControlType, Class etc. XPaths are brittle to locate and sometimes slowdown your test process too. If you refer below mentioned links, they too state that XPath locator has been given the least priority.

   • ID
   • Name
   • Class
   • TagName
   • CSS
   • XPath

Link1 , Link2, Link3

but how to use and pair which type of locator can be provided by approach mentioned in step. There are multiple tools available which can generate or let you know the find expression (in addition to the record feature of tool itself) like Developer Toolbar (for IE and Chrome), Firebug (+ Firepath) etc.

3. Third approach or the proactive approach is to discuss this with Developers so that they include some unique identifier in their technical design and follow the same too, like considering the future automation use, you can ask them to assign unique ID to all possible elements over a page. If some elements are dynamically created then use some other approach for them like TagName or Element Name containing/starting with unique value and then appending the Dynamic ID. Using this proactive approach you will know from the very beginning that which locators you have to use while designing your tests.

Answer 2

There are a lot of guidelines that will help you in choosing good, reliable, reusable, maintainable selectors. Simply inspecting an element and copying its xpath is one of the worst approaches.
When selecting an element:

• Don't overspecify thus 'hard-coding' to the current layout and presentation
• Don't underspecify wuth selectors that aren't unique or specific enough
• Do use css ID fields
• Don't use ID's that are used for data ID's
• Prefer avoiding using layout tags such as table,tr, td
• Prefer avoiding style tags such as b, i
• Consider using data-element attributes, e.g. data-last-name, data-first-name

e.g.

NOT-SO-GOOD

body table tr tr td td td span span table tr td td td div   # Way Too specific
                             (this is what browser examine xpath might give you)

body table tr tr td td td   # Still too specific
span                        # Too unspecific
div[@id=942]                # Uses data id
div span b a#first_auto     # Uses layout

BETTER

.autos #auto li
.insurance_company li[data-primary-vehicle]
.vehicle .model div.primary

In addition to the benefits listed above you can also see that using the 'BETTER' selectors would lead to more human-readable tests as the selectors used are very descriptive of the data they are manipulating.

The tools you should use are the various built-in or add-on DOM inspection tools (like firebug for firefox for example) that let you look at the source. The most important step is you figuring out what parts of the path you see and how to use them.

For trouble-shooting, use the console to try and select parts of the path. For example if the path is .autos #auto li you can try using the console to select .autos and then .autos #auto and then .autos #auto li to see which are valid/invalid.

Answer 3

In Chrome: Inspect element -> Copy -> Copy XPath.

Answer 4

To answer all your 3 questions:

1. If you use xpath, I found the functions from here are very helpful.
2. From my experience so far, automatically generated expressions from any tools are not as good as what we manually come up with. You may refer to my another answer from here.
3. When expressions fail to locate the elements, I write a bunch of similar expressions in debug mode with the consideration of the following:
   • Make the expression a collection instead of a single element (make it a collection type or an array accordingly), then traverse through the elements;
   • Sometimes, the element is just located in another layer as many as 5-6 levels down or up. I write up a bunch of expressions for all possible layers by looking close into DOM structure. I know it's clumsy, but hey it works for me.

Hope these helps.