Test Runner and Commands

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 clears every alias before each test. Mocha's before() hook runs once per suite, so its alias survives into the first test only, and later tests fail with could not find a registered alias. Register it in beforeEach() instead.

Cypress inherits Mocha's hooks. Each before runs once when its describe block starts; then for every it, beforeEach runs, the test runs, afterEach runs; after runs once when the block ends. Outer blocks wrap inner ones.

A Cypress query such as cy.get() or .find() is a repeatable read: it re-runs and relinks the chain until the next assertion passes. An action such as .click() changes the app, so it fires once and never relinks.

It skips eight things at once: scrolling into view and the not-hidden, not-disabled, not-detached, not-readonly, not-animating and not-covered checks, plus firing at a descendant. The event goes straight to the element you targeted.

Cypress warns in the browser console, then hands Mocha your async function's promise instead of its own command-queue promise. Commands still run in written order once the body yields, so await buys nothing and loosens the test's completion signal.

A returned value becomes the subject of the next Cypress command. Returning nothing leaves the previous subject in place - unless the callback issued Cypress commands, in which case the last of those commands' yield carries on instead.

Cypress clears the page by visiting about:blank and clears cookies, localStorage and sessionStorage in all domains. Everything else, IndexedDB above all, survives untouched, so a test that needs an empty IndexedDB must clear it itself.

Exactly once. .then() is not a query, so Cypress never re-runs it or anything before it; an assertion after it keeps retrying against the single value the callback already yielded, then times out.

The whole linked run of queries re-runs from the top. Cypress re-executes cy.get() against the current DOM, feeds the result into .find(), and re-checks the assertion, looping until it passes or defaultCommandTimeout expires.

They never run. A failed Cypress command ends the test — everything still queued behind it is abandoned and the test is reported failed. Cypress offers no catch handler on a command, so a step cannot recover and carry on.

A Cypress retry repeats only the test and its beforeEach and afterEach hooks. Suite-level seeding in a before hook is not repeated, and the backend is not rewound, so the second attempt runs against a catalogue whose last copy is already on loan.

They set how many extra attempts Cypress gives a failing test: runMode applies to cypress run, openMode to cypress open. Both default to 0, so an unconfigured suite never retries a failing test at all.

Cypress's .click() and .rightclick() default to multiple: false and refuse a subject holding more than one element, telling you to pass { multiple: true }. .dblclick() ships with multiple: true, so it double-clicks each matched element in turn without being asked.

Because Cypress reads it as mixing async and sync code: the callback queued commands that have not run yet, then handed back a finished value. Cypress throws with the message that cy.then() failed because you are mixing up async and sync code.

Most Cypress commands mutate browser state — they navigate, set cookies, fire clicks. Running them at once would make a result depend on timing, so Cypress drains its queue one step at a time, each finishing before the next begins.

Cypress's .its(path) reads a property off the yielded subject and yields its value; .invoke(name, args) calls a method of that name and yields what it returns. A property holding a function comes back from .its() uncalled.

cy.get('@books') re-runs the query chain stored with the alias, so it yields a fresh result on every read. this.books is a snapshot written onto Mocha's test context when .as() ran, and it needs a function() test, not an arrow.

Read the second element in the message: that is what sat at the point the click would have landed. Cypress tests only that one point, and it has already tried nudge-scrolling if the coverer was fixed or sticky.

Cypress 16 changed .type()'s default keystroke delay from 10 milliseconds to 0, so the whole string now goes in with no gap. A debounced typeahead that used to fire a request per pause now fires once, and timing-dependent assertions change with it.

Cypress bundles Bluebird and exposes it as Cypress.Promise. When a queued step's callback returns one, Cypress holds the drain and does not start the next queued command until that promise settles, so real async work fits inside the queue's order.

As of Cypress 16, .invoke() is a query: it re-runs whenever a command chained after it retries, so the method fires again on every attempt. End the chain at .invoke(), or call the method yourself inside a .then() callback.

Keep the slow work in before() and capture its result into a variable in the describe scope from inside a .then() callback, then re-register a cheap alias for every test with cy.wrap(value).as('name') in beforeEach().

The test the hook was running for is reported as failed, and every remaining test in that suite is marked skipped rather than run, because the same hook would fail for each of them. A root-level hook skips all remaining tests.

A mid-chain assertion is a retry boundary. Once it passes, Cypress locks in the subject at that point, so later queries retry from that element instead of re-querying from the top - and a re-render leaves it detached.

Because an action fires once and cannot relink. Cypress will not re-run the queries in front of .click(), so the chained .should() gets the exact node the click landed on — and a re-render leaves that node detached.