Cypress

Cypress re-runs a fixed readiness list before every action: it scrolls the element into view, then requires it to be attached, visible, enabled, not readonly, not animating and not covered at the point the event will land.

Cypress reads curly braces in .type() as special key sequences rather than literal characters, so {enter} presses Enter and {selectall} selects the field. An unrecognised sequence throws. Type a literal brace with {{}, or pass the option parseSpecialCharSequences: false.

A Cypress chainer object: a handle you use to append more commands to that chain. It holds no element and no jQuery data, because at the moment the assignment runs cy.get() has only been queued, not executed.

Cypress commands do not run when you call them. Each cy call only appends a step to an internal command queue and returns immediately; Cypress drains that queue, one step at a time, after the test body function has returned.

cy.wrap() starts a Cypress chain whose subject is the value you hand it - a plain object, a number, a jQuery element or a promise - so queries, .should() assertions, .its() and .invoke() can run against it.

Cypress makes Chai's expect and assert global in every spec, so inside .then(($rooms) => ...) you call expect($rooms).to.have.length(4) straight on the yielded subject. A throw from that expect fails the test at that command.

It attaches a Chai-jQuery assertion to the preceding cy.get(), and Cypress keeps re-evaluating the query and the check until the element's text matches or the four-second default command timeout expires, then fails the test.

Pass a CSS attribute selector to cy.get(), as in cy.get('[data-cy="room-card"]'). Cypress ships no dedicated test-id command: the attribute is ordinary markup and the selector is ordinary CSS, matched the way jQuery's $() matches, with data-cy carrying no special status.

A Cypress chain carries a concrete DOM node, not the selector that found it. A re-render throws that node away and mounts a fresh one, so the node your chain still holds is no longer in the document.

One jQuery-wrapped collection holding all 12 room-card elements, not a single DOM node and not an array. Its length is 12, and the whole set becomes the subject the next command in the chain receives.

cy.wait on an intercept alias yields one interception object for that request-response cycle: request and response, plus id, routeId, and an error property when the request failed. Chain .its() or .then() to assert on it.

Cypress accepts cy.intercept(url), cy.intercept(method, url) and cy.intercept(routeMatcher). A bare url matches every HTTP method; the method form narrows it to one; the routeMatcher object matches fields such as pathname, query and headers together.

The response argument. A Cypress cy.intercept('GET', '/api/forecast') with no second argument only spies, and the request still reaches the real server. Supply a StaticResponse, a plain body, or a handler that calls req.reply() and Cypress answers it instead.

A 500 stub sends a real HTTP response the application can read, so its status and error body are available. forceNetworkError destroys the browser connection instead: no status, no headers, no body, and the app's fetch rejects.

Because Chrome, Chromium and Edge now intercept on the native browser network. The browser negotiates the protocol with your server directly, and that is not known when the request is paused, so Cypress reports no value rather than a wrong one.

cy.exec() was removed in Cypress 16 and now throws; use cy.task() instead, calling a handler registered under the task event in setupNodeEvents. The execTimeout option was removed with it, and taskTimeout, default 60000 ms, replaces it.

Cypress joins the path onto fixturesFolder, which defaults to cypress/fixtures. If that exact file exists it is read; otherwise Cypress tries a fixed extension list, .json first, and yields the first match, parsed according to that extension.

Make it a custom command only when the behaviour is wanted across all your specs, such as signing in or seeding an expense report. A step that one spec file repeats should stay a plain JavaScript function in that file.

The id is the cache key. Cypress runs the setup function only when no valid session is saved under that id; every later call with the same id skips setup and re-applies the cached cookies, localStorage and sessionStorage.

It decides how your command treats the subject the previous command yielded: false makes a parent that ignores it, true a child that receives it, optional a dual command that works either way. element, document and window also validate it.

Cypress ships no cy.mount command. You import mount from a framework adapter - cypress/react, cypress/vue, cypress/angular or cypress/svelte - and register it once with Cypress.Commands.add('mount', mount) in cypress/support/component.js, which loads before every spec.

Create a Cypress spy with cy.spy(), name it with .as(), and pass it into cy.mount() as the prop. Drive the component, then assert through the alias: cy.get('@onRate').should('have.been.calledWith', 4). The alias is what makes the assertion retry until the callback fires.

Cypress renders components into cypress/support/component-index.html, not your application's page, so nothing the app's entry file does at startup has run. Import your global stylesheets in cypress/support/component.js, or add the same link tags to that index file.

cy.get('@alias') is a Cypress query, so the chained assertion is re-run against the spy until it passes or defaultCommandTimeout expires. A bare expect(spy) inside .then() is plain Chai: it runs once, at that instant, and loses the race whenever the callback is late.

Cypress mounts the component in a real browser, so every test pays for a compiled dev-server bundle, a loaded page, real layout and paint, and a snapshot per command. That buys a real box model, real visibility and real CSS.

cypress/base carries Debian, Node.js and the OS packages Cypress needs, but no browser. cypress/browsers adds Chrome, Firefox and Edge. cypress/included adds a tag-pinned Cypress installed globally. cypress/factory generates a custom image when no published combination fits.

cypress open launches the interactive Cypress app: you pick a spec, watch it run in a visible browser, and it reruns every time you save. cypress run executes matching specs once, headlessly, then exits with a status code a pipeline reads.

At least one test in that run failed an attempt and then passed on a later attempt of the same code. Cypress Cloud counts those tests and badges the run, so a run can finish green and still be flaky.

Two things: a projectId in the Cypress config (or CYPRESS_PROJECT_ID) naming the Cloud project, and a record key passed as --key or exported as CYPRESS_RECORD_KEY. The projectId says where; the key authorises writing there.

By default cypress run exits with the number of failed tests, Mocha-style: three failures give status 3, and 0 means everything passed. Passing --posix-exit-codes makes any test failure exit 1 instead, and adds 112 for a Cypress Cloud network failure.

Cypress 16 launches Chrome-family browsers - Chrome, Chrome for Testing, Chromium and Edge - plus Firefox, experimental WebKit, and the deprecated bundled Electron. Choose one per run with the --browser flag, or set defaultBrowser in the Cypress config.

Cypress runs inside the browser and obeys the same-origin policy, so a test is bound to one origin and cannot touch a document from a different one. Wrap the commands for the new origin in a cy.origin() block.

Cypress drives a single tab and has no tab-switching command, so assert the link rather than follow it: check its href and target attributes, request the URL directly with cy.request, or strip the target attribute so the click navigates the current tab.

Spec code is evaluated inside the browser, so console.log() writes to that browser's DevTools console. The terminal belongs to Cypress's separate Node process, which only prints what code in cypress.config.js and its Node handlers log.

Cypress ends the request itself and answers 503, adding an x-cypress-matched-blocked-host header naming the pattern that matched. The request is never sent, so it resolves immediately instead of waiting on a third party.

Cypress.env() hydrated every configured environment variable into the browser, so reading one value exposed them all. Cypress 16 removed it and split the job: cy.env() reads secrets asynchronously and keeps them in Node, while Cypress.expose() serves public values synchronously.

The testing-type-only keys: baseUrl, specPattern, supportFile, excludeSpecPattern, slowTestThreshold and testIsolation. Cypress refuses to start and names the offending key if one of them appears at the root of the exported object, telling you to move it into e2e or component.

Only four: cy.fixture(), cy.readFile(), cy.writeFile() and cy.task(). Spec code is browser JavaScript with no fs module, so each of those hands the work to the Node process that loaded the Cypress config.

It must return a value, null, or a promise that resolves to one of those. Returning undefined fails the calling command with a message naming the task, because Cypress reads undefined as "no handler answered this event".

cy.env() logs only the key names you asked for, and that protection ends when it yields. The object you receive is an ordinary JavaScript object that Cypress does not mask or track, so assertions, .its(), .invoke() and failing commands all print what they touch.

One PNG per failed test, written under cypress/screenshots, because screenshotOnRunFailure defaults to true. No video: the video option defaults to false, so cypress/videos stays empty until you enable it. Neither of those happens in cypress open mode.

cy.pause() stops the spec before the next queued command and hands control to the Command Log, where Resume finishes the run and Next advances exactly one command. While stopped you can click through the application, inspect the DOM, and read network traffic and storage.

Hovering a Cypress Command Log entry restores the app under test to the DOM snapshot taken when that command ran. Clicking pins that snapshot so it stays put, and prints the entry's console properties to the browser console.

viewport captures the application as it fits the current viewport, fullPage scrolls and stitches the whole application top to bottom, and runner captures the entire browser viewport including the Cypress Command Log. The default is fullPage.

A bare debugger in the test body runs immediately, before any queued cy command has executed, so it stops on an untouched page. .debug() is itself queued, so it fires in order, with the previous command's subject in hand — the same effect as a debugger inside .then().

Cypress fits an application your own team owns: JavaScript or TypeScript, one superdomain per test, Chrome-family or Firefox. The classic misfits are third-party sites, two-browser or second-tab flows, a real Safari or mobile-device sign-off, and spidering or performance work.

Cypress loads your spec into the browser alongside the application, so both run in the same run loop. Nothing is serialized between a command and an element: the test holds the real window, document and DOM nodes directly.

JavaScript and TypeScript, and nothing else. Cypress evaluates spec code inside the browser alongside the application, so the only language it can ever run is the language of the web; the docs list this as a permanent trade-off.

Waits for an element to appear, become visible or change text vanish: cy.get() and .should() retry inside defaultCommandTimeout. Network waits become cy.intercept() plus cy.wait('@alias'). Waits on state outside the browser do not vanish at all.

Cypress has no first-class XPath support: cy.get() takes a CSS selector. Text-based XPath becomes cy.contains(), structural XPath becomes a CSS selector, and XPath axes become traversal commands such as .find(), .parent(), .next() and .eq().