Of the many findElement(s)/By functions in Selenium, when would you use one over the other?

Selenium includes findElement functions, like so…

.find_element_by_

id
link_text
partial_link_text
name
class_name
tag_name
css_selector
xpath

It’s apparent that some are limited by design due to how the HTML page was created, such as id, link_text, name, tag_name, as not all tags may contain an id, link_text, etc… However, the css_selector and xpath can do pretty much everything these can do, and then some, but seem to be limited on what they can interact with. For example, some buttons might not be able to get clicked with the xpath, but can get clicked by css_selector.

So i’m wondering, when would one want to use one over the other(specifically xpath or css_selector)?

Are the other functions(id, link_text, etc), pretty much not useful, since (at least) I find that xpath/css_selector can do it as well?

Are there any benefits to using, lets say, link_text, over xpath/css_selector?

In my experience CSS is the preferable selector because it can be concise, is well documented and web developers are likely to have more experience and exposure to it.

id, name, tag_name and class_name can all be easily reproduced with simple CSS so I would avoid explicitly using those.

e.g.

id ; #my_id

name; [name=”my_name”]

tag_name; my_tag

class_name; .my_class

The use of XPath is often much maligned; labeled as slow and unstable. However I disagree with this view point.

When I interview people I cringe when they say they avoid Xpath because it is slow and brittle. The speed is no longer a concern, and xpath is only as brittle as the person who wrote it. However, I prefer the syntax of CSS Selectors so that is why I would choose over XPath for the majority of use cases.

There are 3 scenarios in which XPath is the better choice;

• Multiple CSS Selectors may be replaced with one XPath query (e.g find element then iterate through sub elements can be performed in one xpath)

• XPath can select based on Text where as CSS Selector cannot

• XPath allows you walk up the DOM Tree which can be really useful if you can only identify a control by its child

I would always avoid selecting by text if possible, but if I had to, I would prefer to use XPath over the built in Link Text and Partial Link Text methods because the Xpath query woudl allow me to be more expressive and allow me to select more than just anchor tags.

Finally, once gotcha when using XPath is that “class” is treated as a literal string rather than an array of class names as supported in CSS selectors;

HTML: <div class="ab cd">

CSS matches: div.ab
CSS matches: div.cd
CSS matches: div.cd.ab
CSS matches: div.ab.cd

XPath matches: //div[@class="ab cd"]
XPath matches: //div[contains(@class, "ab")]
XPath matches: //div[contains(@class, "cd")]
XPath matches: //div[contains(@class, "ab") and contains(@class, "cd")]

XPath DOES NOT match: //div[@class="cd"]
XPath DOES NOT match: //div[@class="ab"]
XPath DOES NOT match: //div[@class="cd ab"]

This question have been asked and answered in numerous forums in different formats. Considering them all if we prioritize the locators the list would be as follows :

• id: Select element with the specified id attribute.
• name: Select first element with the specified name attribute.
• link_text: Select link (anchor tag) element which contains text matching the specified LinkText.
• partial_link_text: Select link (anchor tag) element which contains text matching the specified PartialLinkText.
• tag_name: Locate Element using a Tag Name.
• class_name: Locate Element using a ClassName.
• css_selector: Select the element using CssSelectors.
• xpath: Locate an element using an XPath expression.

So the question now is Whats New?

The answer is Selenium have evolved a lot recently. WebDriver is now a W3C Recommendation Candidate. Things within Selenium are changing pretty fast. It’s no more only about choosing the locator. We need to use a locator which will :

• Uniquely identify an element.
• The performance of the locator must be optimized.

Keeping these two factors in mind, the best strategy would be to Mock the DOM. The W3C Recommendation Candidate does mentions the list of the locators as per the below :

So the verdict is clear and concise.