Selenium interview question
Which locator strategies do you use in Selenium, and how do you choose?
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
- 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. - A unique, meaningful
idorname, provided it is not auto-generated (id="input-8f3a2"from a component library changes between builds). - A short CSS selector built from stable attributes:
form#login button[type='submit']. - 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'), usecontains()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