What can a Cypress test do to the app under test that an out-of-process runner cannot?

## The privilege, stated precisely Because the spec executes inside the page, every object the application creates is an object the test already holds. There is nothing to fetch and nothing to decode, which turns a family of otherwise awkward test problems into ordinary JavaScript. The commands that expose it are few and worth knowing by name: - **`cy.window()`** yields the application's own `window`. Chain `.its('key')` to read what the app hung there and `.invoke('method', arg)` to call it. - **`cy.document()`** yields the page's `document` the same way. - **`cy.stub()` and `cy.spy()`** replace or wrap a function the application owns, so a branch can be forced -- an empty result, a rejected promise, a third-party widget's callback -- without arranging the real conditions that would produce it. - **`cy.clock()`** overrides the page's `setTimeout`, `setInterval`, `clearTimeout`, `clearInterval` and `Date`; **`cy.tick(ms)`** then advances that clock synchronously, so a thirty-second poll fires at once. - **`Cypress.$`** is the jQuery that Cypress bundles, querying the application's DOM synchronously at the moment the line runs. An out-of-process runner is not shut out of all of this, but it reaches it by shipping an expression into the page and getting a serialized result back. Anything not serializable -- a function, a class instance, a live node -- has to be flattened first, and the round trip is per interaction. In Cypress there is no round trip, because there is no boundary to cross. ## What this changes in a real spec Consider a team running a two-week Cypress pilot against a shipment tracking console while deciding whether to migrate the suite. Three scenarios that were previously expensive collapse: 1. **A delivery exception arriving over a poll.** Instead of waiting out the poll interval, the pilot spec calls `cy.clock()` before `cy.visit()`, pushes the record into the console's own feed with `cy.window().its(...).invoke(...)`, then calls `cy.tick()` and asserts on the rendered row. 2. **The empty state.** Rather than emptying a shared database, the spec stubs the function the console calls for its shipment list and forces it to return nothing. 3. **A third-party map widget.** Instead of driving an unautomatable canvas, the spec calls the widget's own method to move the viewport, then asserts on what the console renders around it. Each one used to need either a fixture pipeline or a sleep. Neither is needed once the test is a co-tenant of the page. ## The trap: synchronous is not the same as ordered `Cypress.$` runs on the line where it appears. It is not one of the queued `cy` commands, so it does not wait for the ones written above it. This is the classic first-week bug in a pilot: - Written directly after `cy.visit()`, `Cypress.$('...')` queries the page that was there **before** the navigation and returns an empty result. - Moved inside a `.then()` callback, or applied to an element a `cy` command already yielded, it reads the DOM the test actually means. `cy.window()`, `cy.document()` and the rest are queued commands and do not have this problem. ## What native access does not buy Being inside the page is not a general escape hatch, and interviewers often probe exactly here: | It does not give you | Why, and what to use instead | | --- | --- | | Server-side modules | The spec is browser JavaScript, so it cannot open a database connection or import a Node module. Send that work to `cy.task()`, or make an HTTP call with `cy.request()` | | Native OS input | Events are dispatched in the browser, not at the operating-system level | | A second origin | Sharing the page's realm means sharing its origin boundary; another origin needs `cy.origin()` | | A second browser | Native access is access to *this* page, not to another driven browser | ## Using the leverage without hollowing out the test The same power that removes the boundary can quietly remove the coverage. The workable habit is to **reach in while arranging and assert through the interface a user has**: seed the console's feed by calling into it, then assert that the row appears on screen with the right status, not that the feed array has the right length. A spec written the other way round passes because the setup ran, which is a fact you already knew. The assertion chainers in that second form -- `have.attr`, `be.visible` -- come from the Chai and Chai-jQuery libraries Cypress bundles, so nothing about the habit costs extra tooling.