Copy<\/button><\/div>\n\nJavascriptExecutor js = (JavascriptExecutor) driver;\n\njs.executeScript(\u201carguments[0].click();\u201d, element);\n\nObject title = js.executeScript(\u201creturn document.title;\u201d);\n<\/code><\/pre><\/div><\/p>\nYou reach for it when a normal WebDriver action can’t do the job cleanly: forcing a click on an element that’s technically covered by something else, reading a value out of a JS variable the page doesn’t render to the DOM, or scrolling. It’s also an escape hatch when a genuine bug in the site (an invisible overlay, a mistimed animation) is blocking a real click, but be careful, a JS click can succeed even when a real user’s mouse click would fail, so overusing it can hide actual UI bugs from your tests.<\/p>\n
<\/div><\/div><\/div>\n
What does running Selenium in headless mode mean, and how do you enable it in Chrome?<\/span>Headless Execution<\/span>Easy<\/span><\/span><\/span><\/button><\/p>\n
Headless means the browser runs with no visible window, no GPU-rendered UI you can watch, just the rendering engine executing in memory. It’s faster to spin up and uses less memory per instance, which is why almost every CI pipeline runs Selenium headless by default.<\/p>\n
java<\/span>Copy<\/button><\/div>\n\nChromeOptions options = new ChromeOptions();\n\noptions.addArguments(\u201c\u2013headless=new\u201d, \u201c\u2013window-size=1920,1080\u201d);\n\nWebDriver driver = new ChromeDriver(options);\n<\/code><\/pre><\/div><\/p>\nAlways set an explicit window size when running headless. Chrome’s default headless viewport is smaller than a typical headed window, and that difference alone can shift where responsive elements land or trigger a different CSS breakpoint, which then breaks locators that worked fine on your local headed run.<\/p>\n
<\/div><\/div><\/div>\n
How do you capture a screenshot in Selenium when a test fails?<\/span>Screenshot Capture<\/span>Easy<\/span><\/span><\/span><\/button><\/p>\n
WebDriver implements the TakesScreenshot interface, so you cast the driver and call getScreenshotAs(OutputType.FILE), then copy that temp file to wherever you want it saved.<\/p>\n
java<\/span>Copy<\/button><\/div>\n\nFile src = ((TakesScreenshot) driver).getScreenshotAs(OutputType.FILE);\n\nFileUtils.copyFile(src, new File(\u201cscreenshots\/\u201d + testName + \u201c.png\u201d));\n<\/code><\/pre><\/div><\/p>\nThe useful place to wire this in is a TestNG @AfterMethod that checks ITestResult.getStatus() and only saves a screenshot on ITestResult.FAILURE, so you’re not littering disk with a screenshot of every passing test. Attach that file path to your report (Extent, Allure) so a failure is visible without anyone re-running the suite locally to see what actually happened.<\/p>\n
<\/div><\/div><\/div>\n
How do you get, add, or delete cookies in Selenium?<\/span>Cookie Management<\/span>Easy<\/span><\/span><\/span><\/button><\/p>\n
driver.manage().getCookies() returns the full cookie set for the current page, getCookieNamed(name) returns one, addCookie(new Cookie(name, value)) sets one, and deleteCookie() or deleteAllCookies() removes them.<\/p>\n
The gotcha is that a cookie is scoped to a domain, and Selenium’s addCookie() call will throw if you try to set one before navigating to that domain first. A common pattern is to skip a slow UI login by driver.get()-ing the target site once, adding a pre-obtained session cookie, then refreshing the page, which lands you logged in without ever touching the login form. It only works if the session cookie itself is still valid server-side, so this approach breaks silently if your test data setup issues a stale token.<\/p>\n
<\/div><\/div><\/div>\n
What's the difference between driver.close() and driver.quit()?<\/span>Close vs Quit<\/span>Easy<\/span><\/span><\/span><\/button><\/p>\n
close() closes only the current browser window or tab. If that was the last window open, the WebDriver session ends as a side effect, but if other windows are still open, the session and the driver process stay alive.<\/p>\n
quit() closes every window associated with that session and ends the WebDriver session outright, which also terminates the underlying driver executable (chromedriver, geckodriver) and the browser process itself. If a test opens multiple windows and you only ever call close() at the end instead of quit(), you leave orphaned browser and driver processes running on whatever machine executed the test. Do that across a few hundred CI runs and you’ll eventually watch a build agent run out of memory for reasons nobody can explain from the test logs alone.<\/p>\n
<\/div><\/div><\/div>\n
<\/span>Medium questions<\/h2>25<\/span><\/div><\/div><\/div>\n
Explain the Selenium WebDriver architecture. What actually happens when you call driver.click()?<\/span>Architecture<\/span>Medium<\/span><\/span><\/span><\/button><\/p>\n
Four pieces are involved: your test script calling the WebDriver client API, the W3C WebDriver protocol (JSON over HTTP), the browser driver executable (chromedriver, geckodriver), and the browser itself. Calling click() sends an HTTP request from the client binding to the driver’s local server, the driver translates that into the browser’s native automation commands, executes it, and returns the result as an HTTP response.<\/p>\n
Selenium 4 dropped the older JSON Wire Protocol translation step for most browsers, since Chrome, Firefox, and Edge had already implemented the W3C spec natively by then. That cut out a whole translation layer and quietly fixed a batch of flaky-command bugs that had nothing to do with anyone’s test code.<\/p>\n
<\/div><\/div><\/div>\n
What's the Actions class for, and when do you actually need it instead of a plain .click()?<\/span>WebDriver API<\/span>Medium<\/span><\/span><\/span><\/button><\/p>\n
Actions handles multi-step gestures a single WebElement method can’t express on its own: mouse hover, drag and drop, right-click (context click), holding a modifier key while clicking, or click-and-hold sequences. You chain steps like moveToElement(), clickAndHold(), and moveByOffset(), then call .build().perform() once to fire the whole sequence at once.<\/p>\n
The common trap is reaching for Actions when a plain .click() would’ve worked fine, which just adds moving parts for no reason. Save it for gestures a single interaction genuinely can’t do. Hover-to-reveal navigation menus are the case that comes up most in real applications.<\/p>\n
<\/div><\/div><\/div>\n
CSS selector vs. XPath: what can XPath do that CSS can't, and does it actually run slower?<\/span>Locators<\/span>Medium<\/span><\/span><\/span><\/button><\/p>\n
XPath can traverse upward in the DOM, selecting a parent or ancestor of an element you’ve matched, and it can match on visible text content. CSS selectors can’t do either natively. The “XPath is slower” claim is mostly leftover folklore from older IE-era browsers; in modern Chromium and Firefox both use native DOM query engines, and the real-world speed gap is negligible.<\/p>\n
What actually costs you with XPath is maintainability, not speed. A long absolute path like \/html\/body\/div[3]\/div\/table\/tr[2]\/td[1] breaks the instant a developer wraps the table in a new div. That’s the real objection, and it’s the one worth raising in an interview instead of the outdated speed argument.<\/p>\n
<\/div><\/div><\/div>\n
What are Selenium 4's relative locators, and when would you actually reach for one?<\/span>Selenium 4<\/span>Medium<\/span><\/span><\/span><\/button><\/p>\n
Relative locators, withTagName(“button”).above(el), .below(el), .toLeftOf(el), .toRightOf(el), and .near(el), find an element by its rendered position relative to another element you can already locate reliably. They’re genuinely useful on forms where a label has a stable ID but the input sitting next to it doesn’t, which happens constantly in auto-generated admin panels.<\/p>\n
The catch: they’re calculated from rendered coordinates, so a responsive layout change, a hidden element, or a reflow can silently break one without any error until the test runs against the new layout. This is a comparatively recent feature (Selenium 4, first released in 2021), and interviewers sometimes ask about it specifically to check whether you’ve kept up with the framework at all.<\/p>\n
<\/div><\/div><\/div>\n
An element's id changes on every page load, something like user-row-48291. How do you write a locator that survives that?<\/span>Locators<\/span>Medium<\/span><\/span><\/span><\/button><\/p>\n
Stop matching the whole ID and match the stable prefix instead. A CSS attribute-contains selector like [id^=’user-row-‘], or an XPath using contains(@id, ‘user-row-‘), both work off the fixed part and ignore the random suffix.<\/p>\n
The more durable fix, if you can influence the app, is asking the dev team to add a data-testid attribute that never changes. Interviews usually just want the CSS or XPath workaround, but naming the better long-term fix unprompted is what separates a strong answer from an adequate one.<\/p>\n
<\/div><\/div><\/div>\n
How does FluentWait differ from a standard WebDriverWait, and when would you actually use one over the other?<\/span>Waits<\/span>Medium<\/span><\/span><\/span><\/button><\/p>\n
WebDriverWait is really a simpler, preset case of FluentWait. FluentWait lets you configure the polling interval directly and choose which exceptions to ignore mid-poll, instead of accepting the library defaults. You’d reach for it when an element’s momentary absence should be tolerated during polling, a loading spinner that briefly detaches and reattaches to the DOM, say, where a plain WebDriverWait would blow up on a transient StaleElementReferenceException instead of continuing to poll through it.<\/p>\n
java<\/span>Copy<\/button><\/div>\n\nWait<WebDriver> wait = new FluentWait<>(driver)\n\n .withTimeout(Duration.ofSeconds(20))\n\n .pollingEvery(Duration.ofMillis(500))\n\n .ignoring(NoSuchElementException.class, StaleElementReferenceException.class);\nWebElement submitButton = wait.until(\n\n driver -> driver.findElement(By.id(\u201csubmit-btn\u201d))\n\n);\n<\/code><\/pre><\/div>A test action opens a new browser tab. How do you interact with it, and get back to the original one?<\/span>Windows<\/span>Medium<\/span><\/span><\/span><\/button><\/p>\n
driver.getWindowHandles() returns the set of every open window and tab handle. Store the original handle before triggering whatever opens the new tab, iterate the updated set, and switch to whichever handle isn’t the one you started with, using driver.switchTo().window(newHandle).<\/p>\n
Handles are opaque strings with no guaranteed order, so assuming “index 1 is always the new tab” is a common bug. Diff the before-and-after handle sets instead of trusting position.<\/p>\n
<\/div><\/div><\/div>\n
How do you interact with a native HTML select dropdown in Selenium?<\/span>Dropdowns<\/span>