skip to content

In Selenium 4, how do you cover a Safari and Internet Explorer mode sign-off for a festival lineup planner?

level: seniorimportance: should knowfreq 40%

answer

  1. Ask which machines exist, not which API
  2. Two targets are pinned to an operating system
  3. One suite, several hosts, one URL
  4. Grid node per platform, capabilities route it
  5. safaridriver on macOS, IE driver on Windows

basics

~20 s

Treat it as a host-placement problem. Safari is driven by safaridriver on macOS, Internet Explorer mode by the Internet Explorer driver on Windows, so one unchanged suite runs against a self-hosted Grid with a node on each platform.

solid answer

~40 s

The matrix, not the API, is the constraint. In Selenium 4, Safari is driven by `safaridriver`, which ships with Safari and runs only on macOS and must be enabled once on the host; Internet Explorer mode lives in Microsoft Edge on Windows and is driven by the Internet Explorer driver configured through `InternetExplorerOptions`. No single machine holds both, so you stand up a self-hosted Grid with a macOS node and a Windows node, point `RemoteWebDriver` at the Grid URL and let the requested capabilities route each session to the matching slot. Keep the exotic legs thin — a narrow sign-off path rather than the whole regression suite — because those drivers move more slowly and Safari permits only one session at a time on a host.

code

java · 12 lines
java
public void safariSignOff() throws Exception {
    SafariOptions safari = new SafariOptions();
    WebDriver driver = new RemoteWebDriver(
        URI.create("http://grid.lineup.internal:4444").toURL(), safari);
    try {
        driver.get("https://lineup.example.test/2026/saturday");
        WebElement headliner = driver.findElement(By.cssSelector("[data-slot='21:00'] .act-name"));
        System.out.println(headliner.getText());
    } finally {
        driver.quit();
    }
}

go deeper

for a junior

Know that some browsers only run on certain operating systems, and that Selenium reaches each one through a driver supplied for that browser rather than through a browser-specific test API.

for a middle

Explain which driver and which host each target needs, and how pointing the same client at a Grid URL lets one test body reach several platforms.

for a senior

Demonstrate the operating judgement: provisioning a node per platform, narrowing what runs on the slow legs, planning for one Safari session per host, and refusing browser conditionals in test bodies.

for a principal

Own the matrix as a cost decision: every exotic browser is machines to buy, patch and monitor, so argue for the smallest matrix that still satisfies the parties who sign off.

## What the requirement is really asking A sign-off that names **Safari** and **Internet Explorer mode** is not primarily a question about test code. Both targets are bound to an operating system, so before anything else it is a question about which machines exist and who runs them: - **Safari** is driven by `safaridriver`, which is part of the Safari installation on **macOS**. It is not downloadable for other platforms, and remote automation has to be enabled once on the host before a session will start. - **Internet Explorer mode** is a mode of **Microsoft Edge** on **Windows**, driven by the Internet Explorer driver and configured in Selenium 4 through `InternetExplorerOptions`. - **Chrome, Firefox and Edge** in their ordinary modes run anywhere, and are the cheap part of the matrix. That is the whole shape of the problem: one leg needs a Mac, one leg needs a Windows box, and the rest needs nothing special. ## Why this decides a runner argument before features do Coverage is the axis that cannot be coded around. If a browser is on the sign-off list and a candidate tool cannot drive it, no amount of bundled convenience closes that gap — and whether any particular tool covers those targets is that tool's own documentation to answer, not something to assume from reputation. Selenium's answer is structural rather than clever: it is a client for the **W3C WebDriver** protocol, so any browser whose vendor ships a conformant driver is reachable with the same commands. That is why Safari and Internet Explorer mode are in the coverage area at all. The converse is just as important in an interview. If the planner only has to be signed off on one engine, the matrix stops being the deciding axis, and the argument moves honestly to what each side bundles. ## Wiring the two hosts into one suite 1. Enable remote automation once on the macOS host so `safaridriver` will accept sessions, and register that machine as a **Grid** node. 2. Register a Windows host as a second node, with a stereotype for Internet Explorer mode alongside its ordinary Edge slot. 3. Build the run so the browser is configuration, not code: the suite reads which target it is running and constructs the matching `Options` object. 4. Point `RemoteWebDriver` at the Grid URL for every target, including the ones that could have run locally, so one code path serves all of them. 5. Let capability matching route the session. A request for Safari can only be satisfied by the macOS node's slot; a request for Internet Explorer mode only by the Windows node's. The test body is untouched by any of this. The same steps that open the lineup grid, switch to the Sunday tab and add a headliner to a plan run on every leg. ## Keeping the exotic legs affordable | Leg | Driver and host | Practical limits to plan for | |---|---|---| | Chrome / Firefox / Edge | Vendor driver, any supported OS | Cheap to scale; fine for the main regression pass | | Safari | `safaridriver`, macOS only | One session at a time per host, so parallel Safari means more Macs | | Internet Explorer mode | Internet Explorer driver, Windows only | Slower, more fragile, and the newest browser features arrive last | Practical judgement for the planner: - Run the **full** suite on the cheap engines and a **narrow** sign-off path on the exotic ones — the flows the ticketing partner actually named, not everything. - Expect capability and feature coverage to lag on the exotic drivers; newer standard surfaces such as **WebDriver BiDi** land browser by browser, so do not build the shared harness on something only Chrome-family targets can do. - Keep browser-specific branching out of the test bodies. If a leg needs different setup, express it in the options and the harness, so the assertions stay one description of the product. - Treat each exotic leg as a machine you own: it has to be patched, unlocked, kept awake and monitored, and that operational cost is the real price of the matrix, not the code. ## The judgement to show A strong answer says the matrix is a **capacity and platform** decision wearing a testing costume: Selenium removes the API problem by standing on a protocol every vendor driver implements, but it cannot remove the need for a Mac and a Windows host, and it will not make those legs as fast or as feature-rich as the Chrome leg. Say what you would put on them, say what you would refuse to put on them, and say who owns the machines.

  • Why can you not simply run the Safari leg on the same Linux node as the Chrome leg?
    Because `safaridriver` is part of Safari's installation on macOS and exists nowhere else. There is no downloadable Safari driver for Linux or Windows, so the leg needs a real Mac registered as a node. That platform constraint is why the matrix is a host-provisioning decision rather than a configuration flag.
  • How do you stop the Internet Explorer mode leg from becoming the slowest, flakiest job in the pipeline?
    Keep it to the narrow path the sign-off actually names, run it on its own schedule rather than on every commit, and forbid browser-specific branching in the test bodies. Treat any behaviour that only reproduces there as a product finding to investigate, not as a reason to sprinkle conditionals through the suite.
  • What breaks first when the same lineup-planner suite runs unchanged on four browsers?
    Assumptions the tests never stated: rendering and layout differences that move an element, timing differences on lazily loaded sections, and features one engine supports and another does not. The protocol is uniform; the browsers are not, and those failures are usually real product findings rather than tooling noise.

saying these in an interview costs you the question

  • Assumes Safari can be driven from a Linux or Windows node
  • Expects a driver download to substitute for a macOS host
  • Thinks Internet Explorer mode is driven by the Edge driver
  • Runs the entire regression suite on every exotic browser
  • Treats browser coverage as a code problem rather than a host problem