16 Selenium .NET and NUnit Interview Scenarios for Senior SDETs

A senior C# Selenium discussion should begin with ownership, not syntax. NUnit may create and schedule fixtures in ways that expose shared fields, while IWebDriver represents a live remote session whose commands mutate one browser. If those lifetimes do not align, polished page objects will still produce cross-test failures.

The scenarios below focus on fixture boundaries, interface design, synchronous binding behavior, remote capability negotiation, and guarded disposal. Each answer should state what the test owns and what evidence remains when that ownership fails.

Map NUnit to WebDriver Lifetime

The official Selenium .NET API defines IWebDriver, browser options, remote sessions, waits, and concrete drivers. Selenium's fresh-browser guidance recommends starting each test from a clean state, with at least a new WebDriver per test when stronger environment isolation is impractical.

The design target is not one driver factory call. It is a complete path in which setup failure, assertion failure, and teardown failure remain distinguishable.

NUnit Fixture Scenarios

1. Why should [SetUp] create a new driver instead of [OneTimeSetUp]?

[SetUp] runs for each test case, so the browser's cookies, windows, profile, and navigation begin from a known session boundary. A one-time driver makes methods order-dependent and lets one crash poison the rest of the fixture. I would reserve [OneTimeSetUp] for immutable configuration or an external client designed for sharing, never a mutable UI session.

2. How would you clean up when setup throws after creating the driver?

Track construction in a local variable and transfer it to the test context only after all mandatory setup succeeds. A catch block disposes the partial session and rethrows the original exception. [TearDown] must also tolerate the absence of a driver. Otherwise a null dereference or disposal failure can replace the useful new-session or navigation error.

3. Why can parallel NUnit methods corrupt an instance-field driver?

The fixture object can expose the same field to concurrently scheduled methods, depending on the configured fixture lifecycle. Each setup assignment races with commands and teardown from another method. I would use an instance-per-test-case lifecycle where deliberately configured or resolve an invocation-scoped browser fixture. The design must be correct under the runner settings actually used in CI, not assumptions from serial execution.

Interface and Page-Layer Scenarios

4. Why should a page service accept IWebDriver but the factory know concrete driver types?

The page needs standard navigation, element lookup, window, and script capabilities represented by the interface. The factory must construct ChromeDriver, FirefoxDriver, or RemoteWebDriver and may configure a local service. Keeping that concrete choice at the boundary prevents tests from casting casually. A browser-specific feature deserves a separate capability interface or adapter with explicit support checks.

5. How would you model a page transition without returning this from every method?

Return the page or domain result that exists after the operation. Login can return a dashboard on success, while a rejected login may return a typed validation result from a different method. Unconditional fluent this chains hide navigation and allow commands against an obsolete page. Constructors can verify a cheap loaded invariant, and transitions should wait for the destination evidence they promise.

6. Why should C# page objects avoid public IWebElement properties?

Public elements expose selectors and remote references to tests, encourage assertions at the wrong level, and can become stale across renders. Keep locators private and expose behavior or immutable values. A component object may hold a root element only for a tightly bounded DOM lifetime; after replacement, the containing page should locate a new component instead of retrying arbitrary operations on stale references.

Parallel Ownership Scenarios

7. How would you allocate one customer record per parallel NUnit case?

Create or lease the record in per-test setup using a run id plus NUnit test id, then pass a typed customer handle to the scenario. The allocator must coordinate through the backend or another atomic store; a static C# counter protects only one process. Cleanup uses the exact id and is idempotent. Reports include a safe alias so collisions can be traced without exposing credentials.

8. Why is ThreadLocal<IWebDriver> not a complete framework architecture?

It maps a value to a thread, but tests can use asynchronous setup, runner scheduling can evolve, and other mutable state may remain static. It also requires explicit disposal and removal. I prefer a test-context resource passed into page services. If ThreadLocal is retained for legacy access, wrap it, fail on missing ownership, and clear it immediately after disposing the driver.

9. How would you size parallelism when Grid has fewer usable slots than NUnit workers?

Match concurrency to the capability-specific capacity, not the Grid's total node count. If workers exceed compatible slots, session creation queues and fixture timeouts can masquerade as application slowness. Set a bounded session-start timeout, expose queue evidence, and separate browser matrices into capacity-aware lanes. Increasing NUnit's parallel level is not useful when downstream ownership cannot be granted.

Wait and Assertion Scenarios

10. Why should WebDriverWait.Until return a typed value when possible?

The delegate can return the element or domain evidence that satisfied the condition, avoiding a second remote read after readiness. For example, return an immutable OrderSummary only when status and total agree. The condition should treat expected transitional states as incomplete and let invalid selectors or disconnected sessions escape. Catching all WebDriverException converts protocol failures into misleading timeouts.

OrderSummary summary = wait.Until(d =>
{
    var value = ReadOrderSummary(d);
    return value.Status == "Confirmed" ? value : null;
});
Assert.That(summary.Total, Is.EqualTo(expectedTotal));

11. How would you avoid assertions disappearing inside page methods?

Page methods return observable values or domain results; NUnit assertions stay in the scenario or a focused domain assertion object. A page constructor may reject an obviously wrong page because that is its invariant. This split makes reports say "confirmed total was wrong" instead of "checkout helper failed" and allows the same interaction to support several legitimate outcomes.

Remote Options Scenarios

12. Why should a framework prefer browser option classes over a loose capability dictionary?

ChromeOptions, FirefoxOptions, and other binding types encode supported standard and browser-specific settings and participate in W3C new-session negotiation. A loose dictionary makes misspelled names and incompatible values easy. I would validate common settings into a target record, build the right options, and isolate any remote provider's namespaced capabilities in one adapter.

13. How would you diagnose requested Chrome but negotiated a different remote environment?

Record sanitized requested capabilities and driver.Capabilities after session creation. Compare browser name, platform, and relevant options with the intended target. The remote distributor may have matched a broader request than expected. If an attribute is mandatory, express it as a valid capability and fail setup when the negotiated session violates the framework contract rather than allowing scenario failures later.

Failure and Disposal Scenarios

14. Why should screenshot capture be guarded separately from browser-log capture?

A closed window can break screenshots while logs or session capabilities remain available; an unsupported log type can fail while the page is still capturable. Run each evidence operation independently and attach its own diagnostic on failure. Then release the driver in finally. One broad artifact block makes the least reliable evidence source capable of suppressing everything else.

15. How would you decide between Quit and Dispose in an ownership wrapper?

Expose one idempotent release operation on the wrapper and follow the binding's disposal contract, ensuring session deletion occurs once. Callers should not scatter both methods or dispose a driver they did not create. The wrapper records whether construction completed and guards repeated cleanup. Finalizers are not a timely test cleanup mechanism; NUnit teardown must release the remote session deterministically.

16. Why is putting Selenium calls inside Task.Run a poor way to speed up one test?

The binding's commands target one stateful session, and concurrent navigation or element operations have dependent browser semantics. Task.Run merely moves synchronous work to pool threads; it does not create independent protocol sessions or make the driver safe for concurrent use. Speed comes from running isolated tests in parallel, reducing unnecessary UI setup, and using APIs for non-UI preconditions.

.NET Framework Checklist

• Align NUnit fixture lifetime with one owned browser per test invocation.
• Keep concrete driver construction and provider capabilities in infrastructure.
• Pass interfaces and typed domain evidence to page and assertion layers.
• Coordinate mutable test data outside process-local static collections.
• Distinguish explicit-wait timeout, remote-command failure, and setup failure.
• Capture each artifact independently before deterministic disposal.
• Validate requested and negotiated capabilities for remote sessions.

Conclusion: Dispose What the Test Owns

The reliable .NET design is straightforward to state and demanding to enforce: one NUnit invocation owns one configured IWebDriver, every page service stays within that lifetime, and teardown preserves evidence before releasing it. Parallelism then becomes a scheduling decision over isolated units, not a gamble over shared fields. That is the standard a senior SDET should defend.