Skip to content
SDETRole
SDETRole

Selenium interview question

Which locator strategies do you use in Selenium, and how do you choose?

beginner 0–2 yrs #locators#css#xpath#data-testid

Short answer

Prefer stable, unique attributes: id or a dedicated data-testid via CSS. Use CSS selectors for most cases and XPath only when you need text matching or DOM traversal CSS can't do. Avoid absolute XPath and styling classes, and agree test IDs with developers.

Answer

Selenium’s By class offers eight strategies: id, name, className, tagName, linkText, partialLinkText, cssSelector and xpath. Under the W3C protocol, id, name and className are actually converted to CSS selectors by the bindings, so in practice you are choosing between CSS, XPath and link text. Selenium 4 also added relative locators (above, below, toLeftOf, toRightOf, near).

My order of preference

  1. A dedicated test attribute, such as data-testid="checkout-submit". It exists only for tests, so a redesign or CSS refactor won’t break it. I ask developers to add these as part of the definition of done.
  2. A unique, meaningful id or name, provided it is not auto-generated (id="input-8f3a2" from a component library changes between builds).
  3. A short CSS selector built from stable attributes: form#login button[type='submit'].
  4. XPath when I need something CSS cannot express: matching visible text, or walking up to an ancestor.
// Good: stable, intention-revealing
By submit   = By.cssSelector("[data-testid='checkout-submit']");
By email    = By.id("email");
By rowByUser = By.xpath("//tr[td[normalize-space()='alice@example.com']]");

// Bad: breaks when layout or styling changes
By fragile  = By.xpath("/html/body/div[2]/div/form/div[3]/button");
By styling  = By.cssSelector(".btn.btn-primary.mt-3");

CSS vs XPath

  • CSS is shorter, familiar to front-end developers and supported identically in every browser. It cannot select by text content or move to a parent.
  • XPath can match text (normalize-space()='Save'), use contains() and traverse axes (ancestor::, following-sibling::). That power also makes it easy to write long, fragile expressions.
  • Performance differences between the two are negligible in modern browsers; choose for readability and stability.

Relative locators

Useful for layouts where a field has no good attribute but sits next to a label:

import static org.openqa.selenium.support.locators.RelativeLocator.with;

WebElement password = driver.findElement(
    with(By.tagName("input")).below(By.id("email")));

They depend on rendered geometry, so they can be sensitive to screen size and responsive layouts. Treat them as a fallback.

Shadow DOM and iframes

Locators don’t cross boundaries. For an iframe, switch with driver.switchTo().frame(...). For an open shadow root, call element.getShadowRoot() and search inside it with CSS (XPath is not supported inside shadow roots).

What interviewers look for

  • A clear priority order that starts with test-specific attributes.
  • Honest CSS vs XPath trade-offs rather than “XPath is slow”.
  • Awareness of brittle patterns and of collaborating with developers on testability.

Common mistakes

  • Copying “Copy full XPath” from DevTools into the framework.
  • Locating by text in a localised application without considering translations.

A strong answer covers

  • Lists the By strategies (id, name, css, xpath, linkText, etc.)
  • Prefers stable, purpose-built attributes such as data-testid
  • CSS vs XPath trade-off: CSS for most, XPath for text/ancestor traversal
  • Avoids brittle locators: absolute XPath, indexes, generated classes
Practise answering under time pressure

Type to search across SDETRole.

Full-text search by Pagefind · runs in your browser Open search page →