webdriver icon indicating copy to clipboard operation
webdriver copied to clipboard

Rethinking the "link text" location strategies

Open alb-i986 opened this issue 5 years ago • 0 comments

Personally I rarely if ever use/have seen using By.linkText/By.partialLinkText in a Selenium project.

The reason is that:

1. Most of the times you are able to locate the link you are interested in by using the ID, the name, the tag, the class or a css selector combining those.

As we know, in fact, those are the best locators. Locating by text is not a best practice, as it may easily make the test flaky (i.e. the link text is more likely to change than, for example, the class of the a element). Choosing to locate an element by text should be really the fallback strategy for testers: only when you have no other options. Maybe the frontenders were rushing out the feature and they didn't leave any meaningful class/attribute whatsoever in the HTML.

2. You rarely need to interact with links anyway

I interact so much with buttons, with form fields, even with divs which behave like buttons, but hardly ever with links. Maybe back in the days links were much more widespread, but I'd say that nowadays you see them only in a navbar, or a menu. Which is only a marginal fraction of the interactions with today's web UIs.

Proposal

For these reasons I think that the constraint on the a tag imposed by the existing link/partial link text strategies is very limiting. Therefore I'm proposing to:

  1. Loosen the constraint on the a tag, extending it to also buttons. Maybe renaming the strategies to "clickable text"?
  2. Make a new, more generic, "text" location strategy, which would target any element in the DOM. If this is gonna be too heavy for the drivers, in terms of performance, maybe we could still keep the constraint on a specific tag, but let the user choose which tag, by taking a parameter somehow. I'm not sure if this is at all possible though.

alb-i986 avatar Jun 06 '20 22:06 alb-i986