Selenium WebDriver Visualizer

The 8 Selenium locator strategies

Selenium finds elements with eight strategies: id, name, className, tagName, linkText, partialLinkText, cssSelector and xpath. In practice you should reach for them in this order:

• ID — fastest and most stable when the element has a unique, non-dynamic id.
• CSS selector — your everyday workhorse: concise, fast, and expressive enough for attribute, class and hierarchy matching.
• XPath — only when you must traverse the DOM (select a parent from a child, or match on visible text with //button[text()="Save"]). It is slower and more brittle, so treat it as the tool of last resort.

Implicit vs explicit vs fluent waits

Flaky tests almost always come down to waits. Know the three types cold:

• Implicit wait — one global polling timeout applied to every findElement call. Convenient but it hides real timing bugs and can slow a suite down.
• Explicit wait — WebDriverWait + an ExpectedCondition (element clickable, visible, present). You wait for a specific state on a specific element, which is the reliable choice for dynamic pages.
• Fluent wait — an explicit wait with a custom polling interval and the ability to ignore specific exceptions (like NoSuchElementException) while it polls.

Never mix implicit and explicit waits — combining them produces unpredictable timeouts.

How the WebDriver architecture works

Your test uses the Selenium client library to send commands as JSON over HTTP to a browser-specific driver — ChromeDriver, GeckoDriver, EdgeDriver — using the W3C WebDriver protocol. The driver controls the real browser and passes the result back up the chain. Understanding this round trip explains a lot: why you need a matching driver version, why headless still uses the real engine, and why a slow network makes every command slower.

How to use this tool

1. Pick a locator strategy in the tool and watch how it resolves against the sample DOM.
2. Switch between implicit, explicit and fluent waits to see how each polls and when it gives up.
3. Trigger a command and follow the request as it travels test → driver → browser → back.
4. Compare a fragile absolute XPath against a stable CSS selector for the same element.

Worked example

A minimal, reliable Selenium test uses an explicit wait rather than Thread.sleep:

WebDriver driver = new ChromeDriver();
driver.get("https://navtutorial.com");

WebDriverWait wait = new WebDriverWait(driver, Duration.ofSeconds(10));
WebElement search = wait.until(
    ExpectedConditions.elementToBeClickable(By.cssSelector("input[name='q']"))
);
search.sendKeys("selenium waits");
search.submit();

driver.quit();

Common mistakes to avoid

• Using Thread.sleep() instead of explicit waits — it is slow and still flaky.
• Mixing implicit and explicit waits in the same driver, which causes unpredictable timeouts.
• Writing absolute XPath like /html/body/div[3]/... that breaks the moment the layout changes.
• Forgetting driver.quit(), which leaks browser processes and drivers in CI.

Frequently asked questions

Related guides & tools