Sample questions
Ta Selenium Cypress Playwright TradeoffsDifficulty 1
How does a Selenium WebDriver client library (e.g. the Java or Python bindings) tell the browser to click an element?
- aIt injects a JavaScript click() call directly into the page's own script context
- bIt writes the command into a shared memory segment that the browser polls
- cIt sends an HTTP request to a driver process, which performs the action in the browser✓
- dIt attaches directly to the browser's rendering engine through a compiled native plugin installed alongside the browser
Explanation:Selenium follows the WebDriver protocol: the client library sends an HTTP request (JSON body) to a driver executable such as chromedriver or geckodriver, and that driver process translates the request into the actual browser action. a describes something closer to how Cypress executes commands in-browser; b and d are not how any of the three tools communicate.
Ta Selenium Cypress Playwright TradeoffsDifficulty 1
Where does Cypress's test code actually execute while a test is running?
- aIn the same browser and run loop as the app under test✓
- bOn a remote grid node, separate from any browser
- cInside the operating system's accessibility layer, outside the browser
- dInside the application's own backend server process, isolated from the browser entirely
Explanation:Cypress test code runs directly in the browser alongside your application's JavaScript, sharing the same run loop; a Node.js process handles tasks that need OS-level access (like reading files) and proxies network traffic. b, c and d do not describe where Cypress test code executes.
Ta Selenium Cypress Playwright TradeoffsDifficulty 1
Which protocol does Playwright primarily use to control Chromium-based browsers?
- aThe classic Selenium JSON Wire Protocol
- bA generic screen-scraping protocol based on pixel comparison
- cIMAP-style polling over a socket
- dThe Chrome DevTools Protocol (CDP)✓
Explanation:Playwright drives Chromium browsers over the Chrome DevTools Protocol (CDP), a WebSocket-based protocol originally built for browser debugging tools. a is Selenium's older protocol lineage, not Playwright's; b and c are not real automation protocols used here.
Ta Selenium Cypress Playwright TradeoffsDifficulty 1
Which of the three tools requires a separate, browser-vendor-specific driver executable (like chromedriver or geckodriver) matched to the installed browser version?
- aCypress
- bSelenium✓
- cPlaywright, for every browser it supports
- dNone of them need any driver at all
Explanation:Selenium's WebDriver architecture depends on a driver executable per browser vendor, and that driver's version must generally match the installed browser version. Cypress bundles its own binary without a separate vendor driver, and Playwright manages its own browser binaries rather than requiring you to install and version-match external driver executables.
Ta Selenium Cypress Playwright TradeoffsDifficulty 2
Why can Selenium be used to automate real Apple Safari on macOS, while Cypress cannot test Safari at all?
- aCypress is too slow to keep up with Safari's rendering speed
- bSelenium can drive Safari through Apple's own safaridriver, whereas Cypress has no Safari-family engine integration✓
- cSafari blocks all HTTP-based automation protocols by policy
- dCypress requires a Windows-only kernel-level driver component that has never been ported to Safari's macOS engine
Explanation:Selenium's WebDriver architecture lets any vendor ship a conforming driver, and Apple provides safaridriver for exactly this purpose, so Selenium can automate real Safari on macOS. Cypress has never integrated a Safari or WebKit-based execution path, so it simply cannot run tests against Safari. a, c and d describe reasons that do not match how these tools actually work.
Ta Selenium Cypress Playwright TradeoffsDifficulty 2
Historically, why did Cypress have restrictions around interacting with a second, different origin (domain) within the same test?
- aCypress refuses to send any network request that is not HTTPS
- bCypress test files are limited to exactly one HTTP request per test
- cSecond-origin pages always render in a special headless-only sandbox mode that Cypress's inspector has no visibility into
- dCypress code runs inside the browser tied to the app's origin, so crossing origins broke execution✓
Explanation:Because Cypress code executes directly inside the browser in the same context as the application, navigating to a genuinely different origin used to break that execution context, which is why Cypress later introduced cy.origin() as a workaround. a, b and c are not real constraints Cypress has ever had.