17.2Category 2: Technical Deep Dives

Q6: "Explain actionability checks. Where should they be implemented?"

Answer: "Five checks run before every interaction — the model Playwright pioneered:

1. Visible — Non-zero dimensions, not display:none or visibility:hidden
2. Stable — Position unchanged across animation frames (catches CSS animations)
3. ReceivesEvents — hit-testing at the element's center reaches the target, not a covering overlay
4. Enabled — Not disabled, aria-disabled, or in a disabled fieldset
5. Editable — (for text input) Accepts input, not readonly

They run in a polling loop until all pass or a timeout fires, and a good implementation tells you which check failed — 'obscured by div.modal-overlay' makes debugging trivial.

The architectural question interviewers like: where should these live? Playwright implements them in each client library. Vibium — Jason Huggins' AI-native tool — made the interesting choice of implementing them once, server-side in a Go binary, so every client gets identical behavior for free. Knowing both designs and the trade-off (per-client flexibility vs single-implementation consistency) is the architect-level answer."

Q7: "What is WebDriver BiDi and why does it matter?"

Answer: "WebDriver BiDi is a W3C standard that combines the best of two predecessors. Classic WebDriver was standardized and cross-browser but one-directional — HTTP request/response, no events. CDP was bidirectional with rich events but Chrome-specific and unstable.

BiDi uses WebSocket for bidirectional JSON messaging — both commands from client to browser AND events pushed from browser to client. It's governed by the W3C with buy-in from all major browser vendors.

And as of 2026 it's the present, not the future: it covers roughly 70% of the CDP surface across Chrome and Firefox, WebdriverIO v9 defaults to it, and Selenium 4 exposes it at the low level with high-level APIs slated for Selenium 5. For our stack it means standards-based, future-proof, cross-browser automation with real-time events — console logs and network activity pushed to us as they happen."

Q8: "How does the CLI approach keep token usage low? Where's the catch?"

Answer: "The mechanism is disk-first state. With MCP, every action streams the page's accessibility tree — often thousands of tokens — into the model's context whether the agent needs it or not. With the CLI, snapshots and screenshots are written to .playwright-cli/ and the agent gets back a file path. The agent reads state on demand.

Microsoft's benchmark: ~27,000 tokens per typical task via CLI versus ~114,000 via MCP — about 4x, with longer sessions reporting up to 10x.

The catch is latency: reading state from disk adds round-trips, so a CLI session can be slower in wall-clock time even while far cheaper in tokens. And in sandboxed environments with no filesystem, MCP is the only option. Token efficiency and latency are different axes — you pick per context, which is exactly what Microsoft's own guidance says."

Q9: "Explain the token economics of skills vs MCP for browser automation."

Answer: "The naive arithmetic makes skills look absurdly better: a SKILL.md is ~1,000 tokens once, a shell command ~30 tokens, versus thousands per MCP action from tool schemas plus accessibility trees. Per-step, that's a double-digit multiple.

The honest, measured number is smaller and more defensible: Microsoft benchmarks a typical end-to-end task at ~27k tokens via CLI versus ~114k via MCP — roughly 4x. The gap between naive and measured matters: in a real task the agent still reads snapshots from disk when it needs them. The saving comes from reading state on demand instead of receiving it on every action, not from never seeing state.

4x is still decisive at scale: it's the difference between finishing a long test session with room to reason and compacting context halfway through. And it compounds with cost — across hundreds of CI runs a day, the CLI path is what keeps agent-driven testing economically viable."

Q10: "How do you handle self-healing tests?"

Answer: "Three tiers:

Tier 1 (most failures, cheapest): When an interaction fails, the agent takes a fresh playwright-cli snapshot and rediscovers the element by role and accessible name in the YAML — element refs come from snapshots, so a re-snapshot is the recovery mechanism.

Tier 2: The agent takes a screenshot and reads the page state to understand what happened — loading spinners, redirects, unexpected dialogs — then acts accordingly.

Tier 3 (productized): Playwright's healer agent replays the failing step against the live app, patches locators, waits, or data, and reruns until green — or concludes the functionality itself is broken.

That last capability is the standard I hold any self-healing system to: a healer that always makes the test pass is a bug-hiding machine. We track healing events in a log. High healing rates on one test mean its assumptions need updating. High healing rates across tests mean a major UI refactor happened. Self-healing should fix stale selectors, not mask real regressions."