20 WebDriver BiDi and CDP Migration Interview Scenarios

Senior BiDi interviews test whether an engineer can reason about two kinds of time at once: ordered WebDriver commands and browser events that arrive independently. Naming the log and network domains is not enough. A credible answer defines when the subscription becomes active, how an event is tied to the right browsing context, and who closes every listener.

The migration question is equally practical. CDP can expose useful Chromium behavior, but its browser-version coupling and vendor scope are architectural constraints. An expert proposes a standards-based path, keeps any temporary CDP dependency visible, and proves behavior across the browsers the product actually supports.

Read the Two-Channel Protocol

The official Selenium BiDi documentation contrasts the traditional request-response model with asynchronous communication over WebSockets. Enabling BiDi requests a WebSocket URL during session creation; it does not make ordinary WebDriver navigation, element, and Actions commands disappear.

At the protocol boundary, commands carry an identifier, method, and parameters. Responses resolve the matching identifier, while events are unsolicited messages identified by method and payload. That distinction drives timeout, concurrency, and error handling.

Session Negotiation Scenarios

1. Why does a test receive no BiDi events even though normal WebDriver commands work?

I would inspect the new-session capabilities first. The client must request webSocketUrl, and the successful response must expose an endpoint the binding can use. A healthy HTTP command channel proves only that WebDriver Classic started. If the Grid, browser, or intermediary does not negotiate the capability, adding listeners later cannot create a BiDi transport. Record requested and returned capabilities without leaking credentials.

2. How would you explain the relationship between the HTTP command channel and the BiDi WebSocket?

They belong to one browser session but serve different interaction shapes. Classic WebDriver sends a command and waits for its response. The BiDi socket can carry commands and browser-originated events while the session is alive. I would keep element interactions on the stable high-level binding and use BiDi for event-driven use cases. Session deletion remains the final ownership boundary for both channels.

3. Why should capability negotiation be tested through a remote Grid as well as locally?

Local success does not prove that a remote endpoint forwards the request, returns the WebSocket URL, or makes that URL reachable from the test runner. A Grid may advertise a routable HTTP address while exposing a socket address with different proxy requirements. I would run a tiny handshake probe through the production route and verify an actual subscribed event, not merely the presence of a capability string.

ChromeOptions options = new ChromeOptions();
options.setCapability("webSocketUrl", true);
WebDriver driver = new ChromeDriver(options);

Subscription and Event-Race Scenarios

4. Why does registering a listener after clicking produce an intermittent empty log?

The click can trigger and complete the interesting browser event before the subscription is active. I would subscribe, attach the handler, establish a completion signal, and only then click. The handler should filter for the expected context and event identity. A sleep after the click cannot recover history and only changes how often the race appears.

5. How would you scope a listener when the test opens a popup and an advertisement iframe also makes requests?

I would capture the popup's browsing-context identifier from its creation path and subscribe or filter against that context. URL matching alone is weak because frames can call the same host. Evidence should retain context, request identifier, method, and URL. The test waits for the popup-specific request and ignores unrelated traffic rather than clearing a shared global list.

6. Why is subscribing to every available event a poor default for a large suite?

Broad subscriptions create memory pressure, noisy artifacts, extra synchronization, and accidental secret capture. They also make tests search huge buffers after the fact. I would activate the smallest event set for the scenario, apply context scope when supported, redact at ingestion, and cap retained entries. Diagnostic collection can be broader on failure, but it still needs a documented retention policy.

7. How should an event handler signal completion without blocking the socket reader?

The callback should do minimal parsing, place immutable evidence into a thread-safe queue or complete a future, and return. It should not call long WebDriver operations or wait for the test thread, because that can stall delivery and create reentrancy surprises. The test owns the timeout and consumes the signal separately. Handler exceptions must be surfaced rather than silently dropped.

Network and Logging Scenarios

8. Why is a network response event not automatically proof that the UI rendered the response?

Protocol evidence proves that the browser observed a response with particular metadata. It does not prove that application code accepted the body, updated state, or painted the right control. I would pair the correlated network event with a user-visible assertion. When the two disagree, the split is valuable: transport succeeded, so investigation moves to parsing, state management, or rendering.

9. How would you test that one failed API call produced the expected console error?

Subscribe to the relevant network and log events before triggering the call. Correlate the network request by context and a stable request property, then bound the log search to the same scenario window. Assert the intended UI recovery separately. I would avoid matching an entire console string, which often contains volatile stack or URL data; classify level, source, and a stable message fragment.

10. Why can a response-body assertion be risky in a general event recorder?

Bodies may be large, binary, unavailable at the chosen event stage, or contain credentials and personal data. A recorder should default to metadata and retrieve a body only for a narrow test that owns the security decision. It should enforce size limits and redaction before attaching anything to CI. Protocol access is not permission to persist every byte the browser sees.

11. How would you diagnose duplicate log entries after several tests run in one process?

I would suspect listeners that were added per test but never removed. Count registrations by session and test identifier, then force a teardown check that the subscription set returns to its baseline. A static event collector is another warning sign. Each driver session should own its callback handles and buffers so quitting one test cannot leave observers attached to another.

CDP Migration Scenarios

12. Why should a team migrate a CDP network helper even when it currently works?

Selenium's CDP guidance states that CDP access is temporary and highly dependent on the browser version. A helper that imports versioned DevTools types or sends raw method names carries upgrade and Chromium-only risk. I would inventory its exact outcome, map that outcome to a BiDi capability, and migrate one consumer behind a common interface before deleting the fallback.

13. How would you handle a required CDP feature that has no usable BiDi equivalent in the supported matrix?

I would keep a deliberately named Chromium adapter, guard it with an explicit browser capability check, and make unsupported execution a visible skip or configuration failure. The domain-facing interface should not expose CDP payload types. This prevents vendor details from spreading and gives the team one place to remove when the standard path becomes adequate. I would not pretend cross-browser coverage exists.

14. Why is replacing raw CDP calls one-for-one with raw BiDi messages incomplete migration?

It changes the wire vocabulary but preserves low-level coupling, ad hoc lifecycle management, and weak tests. I would first define the outcome the framework needs, such as collecting failed requests for one context. Then implement it with the binding's supported high-level BiDi API where possible. The adapter should own subscription, correlation, timeout, redaction, and cleanup, leaving tests independent of protocol shapes.

Concurrency and Cleanup Scenarios

15. How should parallel tests prevent BiDi events from crossing session boundaries?

Never place all events in one mutable process list. Give each driver an event collector tied to its session id, then partition again by browsing context or request identity. The test obtains a snapshot from its collector. Parallel workers can share immutable configuration, but not sockets, callback registries, or buffers. Teardown should assert that the collector stopped accepting events after session closure.

16. Why can quitting the driver before removing listeners make diagnostics confusing?

Socket closure and listener callbacks can race with teardown. The report may show a transport error instead of the original assertion, or a callback may write after artifacts were finalized. I would stop accepting new evidence, unsubscribe where the API permits, snapshot the buffer, and then quit the driver in a guarded finalizer. Cleanup errors are attached separately from the primary failure.

17. How would you design a timeout for waiting on an asynchronous browser event?

The timeout belongs to the scenario, not to an unbounded queue read. Start it only after subscription is confirmed and the triggering action begins. On expiry, report the requested event, context, correlation filter, recent matching candidates, and session capabilities. I would not automatically retry the whole test until determining whether the missing event reflects application behavior, unsupported protocol functionality, or an observer race.

Architecture and Review Scenarios

18. Why should a framework expose domain evidence instead of raw event payloads?

Raw payloads make every test understand protocol field names, optional values, and event sequencing. A domain collector can return FailedRequest, ConsoleFault, or NavigationEvidence records with stable semantics. It also centralizes redaction and compatibility work. I would retain the raw payload only as bounded diagnostic material, not as the assertion API consumed across the suite.

19. How would you prove a CDP-to-BiDi migration did not reduce coverage?

Define observable contracts before changing implementation: which requests are captured, which contexts count, what error metadata is required, and what UI outcome is asserted. Run old and new collectors side by side on controlled scenarios, compare normalized evidence, and exercise every supported browser. Differences should be reviewed semantically; byte-for-byte event equality is neither expected nor a useful product guarantee.

20. Why is graceful degradation better than silently falling back to no evidence?

If a requested BiDi capability is unavailable, returning an empty list looks exactly like "no browser errors" and creates a false pass. The adapter should fail setup for mandatory evidence or mark an explicitly optional diagnostic as unavailable. It should include the negotiated capability and browser identity. Silent absence turns an infrastructure limitation into an incorrect statement about product quality.

Candidate Review Checklist

• Negotiate and verify the socket before claiming BiDi coverage.
• Register subscriptions before the action that can emit the event.
• Correlate by session, context, and protocol identifiers instead of timing alone.
• Keep event handlers short and buffers bounded, redacted, and session-owned.
• Treat network evidence and visible product behavior as separate assertions.
• Isolate temporary CDP code behind an explicit browser-specific adapter.
• Unsubscribe, snapshot diagnostics, and close the session in a defined order.

Conclusion: Make Asynchrony Explicit

A strong BiDi design never depends on being lucky enough to hear an event. It negotiates the transport, activates a narrow subscription before the trigger, correlates the resulting payload, and removes the observer when the evidence is complete. Migrate CDP by product outcome, preserve an honest fallback only where necessary, and fail visibly when the promised observation cannot be made.