Cypress Interview Questions & Answers (2026)

Calling cy.get('#name') does not perform anything. It enqueues a command. Cypress builds the entire chain synchronously as your test function runs, then executes the queue asynchronously, one command at a time, after the function has returned.

The consequence: you cannot assign a command's result to a variable, and await cy.get(...) is meaningless because a command is not thenable in the way a promise is.

// Wrong — text is a Chainable, not a string
const text = cy.get('h1').text();

// Right — work inside the callback
cy.get('h1').invoke('text').then(text => { expect(text).to.contain('Orders'); });

Each command yields a subject to the next one. cy.get('form') yields a jQuery-wrapped element; .find('input') receives it and yields the matching inputs; .type('x') receives those and yields them unchanged.

Commands fall into three kinds: parent commands start a fresh chain and ignore the incoming subject (cy.get, cy.visit, cy.request); child commands require a subject (.click, .find); dual commands work either way (cy.contains). Chaining a parent command after a child silently discards your subject — a common source of confusion.

.then() runs your callback once with the current subject and does not retry. .should() attaches an assertion that Cypress retries until it passes or times out.

// Retries until the badge reads 3
cy.get('[data-cy=cart-count]').should('have.text', '3');

// Runs once — flaky if the count is still updating
cy.get('[data-cy=cart-count]').then($el => {
  expect($el.text()).to.eq('3');
});

Use .then() when you genuinely need imperative logic (extracting a value, branching), and put the waiting-sensitive assertion in .should().

.should(callback) retries the entire callback until it stops throwing. That makes it the right place for multi-part assertions on state that is still settling.

cy.get('li.item').should($items => {
  expect($items).to.have.length(3);
  expect($items.eq(0)).to.contain('Alpha');
});

Because it retries, the callback must be side-effect free — never put a cy.request, a click or a counter increment inside it, or it will fire multiple times.

Because at the moment your if evaluates, the queue has not run — and even inside a .then(), the DOM may not have finished settling, so the branch you take is a race.

Cypress's position is that tests should be deterministic: you should know whether the banner appears. Where the state genuinely varies, make it deterministic first — seed the account through the API, stub the response with cy.intercept, or set the feature flag via cy.setCookie/local storage — rather than branching.

If you truly must branch, do it on a source that is already resolved (a cy.request response body), not on the rendered DOM.

Buys: direct access to the application's window, document, local storage and even app internals; native access to the same event loop, which is why command feedback is instant; time-travel snapshots per command; and stubbing of browser APIs (cy.clock, cy.stub on window).

Costs: the runner is subject to the same browser rules as the app. That is the direct source of the origin restrictions, the absence of real multi-tab support, and the limits on native OS dialogs and file pickers. A Node-side process (the plugin/setup layer) exists precisely to do the things the browser cannot.

Cypress uses Mocha hooks: before, beforeEach, afterEach, after.

With testIsolation enabled (the default in current Cypress), the browser context is cleared before each test — cookies, local storage and session storage are wiped and the page is reset to about:blank. So you do not need manual clearCookies calls; you need a beforeEach that establishes the state your test requires, ideally via API or cy.session.

Cleanup in after is unreliable — if a test fails hard, later hooks may not run. Prefer creating uniquely-named data so leftovers are harmless.

Two reasons: a failing test may abort before afterEach completes, leaving state behind anyway; and a failure inside cleanup produces a confusing second error that hides the original one.

The recommended pattern is set-up-forward: create fresh, uniquely identified data at the start of each test (order-${Date.now()}), so previous runs never interfere. Reserve teardown for resources that genuinely cost money or block others, and run bulk cleanup as a scheduled job rather than per test.

Cypress retries only the last query command before an assertion, together with the assertions attached to it. Action commands such as click or type are not retried; they are attempted once the element passes actionability checks.

// Both get and find are re-queried until the assertion passes
cy.get('table').find('tr').should('have.length', 5);

// The .then() breaks retry-ability — everything before it ran once
cy.get('table').then($t => $t.find('tr')).should('have.length', 5);

This is why inserting .then() in the middle of a chain is the most common way people accidentally make a stable test flaky.

Because it is either too short (flaky under CI load) or too long (wasted minutes across a suite), and it never states what you were actually waiting for.

Cypress gives you better tools: assertions retry automatically, so cy.get('.row').should('have.length', 10) already waits; cy.wait('@alias') waits for a specific intercepted request to complete; and cy.get(sel, { timeout: 20000 }) raises the wait for one known-slow element without slowing the rest of the suite.

• defaultCommandTimeout (4 s) — how long query commands and assertions retry. The one you tune most.
• requestTimeout (5 s) — waiting for an intercepted request to be sent.
• responseTimeout (30 s) — waiting for the response, and for cy.request.
• pageLoadTimeout (60 s) — cy.visit and navigation.
• execTimeout, taskTimeout — Node-side commands.

Prefer a per-command { timeout } override to raising the global value; a global increase makes every genuine failure take longer to report.

cy.get('[data-cy=spinner]').should('not.exist');       // removed from DOM
cy.get('[data-cy=banner]').should('not.be.visible');   // present but hidden

The distinction matters: not.be.visible fails if the element was removed entirely, because the query finds nothing to assert on. Use not.exist for elements the app unmounts and not.be.visible for elements it merely hides.

Also beware asserting absence immediately after page load — the element may not have rendered yet, so the assertion passes for the wrong reason. Anchor it: assert the loading state appeared first, then that it disappeared.

Cypress already waits for an element to stop animating before acting on it (waitForAnimations, with an animationDistanceThreshold). Problems usually come from assertions on position or from CSS transitions that never quite settle.

Practical options: assert on a stable end-state class the app adds when the transition completes; disable animations in the test environment via injected CSS, which also speeds up the suite; or as a last resort pass { force: true } — while being clear that force bypasses actionability and can hide a genuine bug.

It skips the actionability checks — visibility, not-covered, not-disabled, scroll-into-view — and dispatches the event directly at the element.

Legitimate uses are narrow: interacting with an element that is intentionally offscreen in a virtualised list, or a hidden file input. Illegitimate use is far more common: forcing a click on a button covered by a modal or cookie banner. That makes the test pass while a real user would be blocked — exactly the bug the test existed to catch.

It happens when a re-render replaces the node between the query and the action. Fixes, in order of preference:

• Re-query rather than reusing a stale subject: chain cy.get(...) again instead of holding an element from an earlier .then().
• Wait for the cause of the re-render first — usually the network call, via cy.wait('@alias').
• Assert the list has settled (should('have.length', n)) before clicking into it.

Retrying the click blindly is a workaround; the underlying issue is acting during a render cycle.

cy.clock() replaces the browser's timer functions and Date with controllable fakes; cy.tick(ms) advances them instantly.

cy.clock();
cy.visit('/session');
cy.tick(15 * 60 * 1000);            // jump 15 minutes
cy.contains('Your session expired').should('be.visible');

This turns untestable time-based behaviour — idle timeouts, polling intervals, auto-dismissing toasts, countdown timers — into fast deterministic tests instead of tests that literally wait.

Prefer a dedicated test attribute — data-cy, data-test or data-testid — because it is the only selector both you and the developers agree is contractual. CSS classes change with restyling, IDs are reused, tag structure changes with refactors, and text changes with copy edits or localisation.

Configure e2e.experimentalStudio aside, the practical rule most teams adopt: user-visible text via cy.contains for things a user would genuinely read, data-cy for everything else, and never a chained descendant CSS selector more than two levels deep.

cy.get(selector) queries by CSS selector (or alias). cy.contains(text) queries by rendered text content, returning the deepest element containing that text — which is often not the element you intended to click.

cy.contains('Delete');                              // could match a <span> inside the button
cy.contains('button', 'Delete');                    // scope by selector — safer
cy.get('[data-cy=row-22]').contains('Delete');      // scope by container — safest

cy.contains does substring, case-sensitive matching by default; pass a regex for exact control.

.as('name') stores a reference; cy.get('@name') retrieves it. You can alias DOM elements, intercepted routes, fixtures and arbitrary values from cy.wrap.

cy.intercept('POST', '/api/orders').as('createOrder');
cy.fixture('user.json').as('user');
cy.get('[data-cy=submit]').as('submitBtn');

cy.get('@submitBtn').click();
cy.wait('@createOrder').its('response.statusCode').should('eq', 201);

Note that a DOM alias is re-queried when used, so it does not go stale — but aliases are cleared between tests, which is why setting them in before rather than beforeEach causes 'alias not found' errors.

Write a custom command when the operation belongs in the command queue — it uses other cy.* commands, needs to appear in the command log, or is used across many spec files (cy.login(), cy.seedOrder()).

Write a plain function when the logic is synchronous and has nothing to do with the browser — building a payload, formatting a date, generating test data. Turning those into commands adds queue overhead and log noise for no benefit.

Cypress.Commands.add('login', (email, password) => {
  cy.session([email], () => {
    cy.request('POST', '/api/login', { email, password })
      .then(({ body }) => window.localStorage.setItem('token', body.token));
  });
});

Read with Cypress.env('KEY'). Values can come from cypress.config.js (env block — for non-secrets), a gitignored cypress.env.json, the CLI (--env key=value), or the OS as CYPRESS_KEY.

Precedence runs CLI > OS env > cypress.env.json > config file. Never commit credentials in the config file: anything shipped to the browser is visible in the runner, so keep genuinely sensitive values in CI secrets and prefer minting short-lived test tokens over storing passwords.

Because the spec file is JavaScript, you loop at build time rather than using a runner feature:

const users = require('../fixtures/roles.json');
users.forEach(({ role, canDelete }) => {
  it(`${role} delete permission is ${canDelete}`, () => {
    cy.login(role);
    cy.visit('/orders');
    cy.get('[data-cy=delete]').should(canDelete ? 'exist' : 'not.exist');
  });
});

For environments, drive baseUrl from config per environment rather than branching inside tests. Keep the loop over a small, meaningful set — generating hundreds of near-identical tests slows CI without adding coverage.

cy.task() runs code in the Node process rather than the browser, so it can do things the browser cannot: query a database directly, read or write files, call an internal service that is not CORS-enabled, or generate a file to upload.

// cypress.config.js
setupNodeEvents(on) {
  on('task', { async resetDb() { await db.query('TRUNCATE orders'); return null; } });
}
// spec
cy.task('resetDb');

A task must return a value or null — returning undefined is an error, which catches most people once.

You can, via cy.task() calling a Node database client. It is genuinely useful for setup (seeding a known record) and for verifying side effects the UI never shows — an audit row, a queued job.

Be sparing about assertions on internal tables in UI tests: they couple the test to a schema that will change, and a failure tells you little about user impact. Prefer asserting through an API the product already exposes, and reserve direct database checks for cases where no such surface exists.

cy.intercept operates at the proxy layer, so it handles all request types — fetch, XHR, page loads, static assets, fonts, images — whereas the removed cy.route only saw XHR.

It also supports dynamic request handlers, request-body modification, response delay and throttle, per-request matching on headers or query, and spying without stubbing (omit the response argument).

cy.intercept('GET', '/api/orders*', req => {
  req.headers['x-test-run'] = runId;
  req.reply(res => { res.setDelay(1500); });
}).as('orders');

Spying: cy.intercept('/api/orders').as('orders') — the real request goes through and you can assert on it afterwards. Stubbing: adding a response ({ fixture }, { statusCode, body } or req.reply()) — the request never reaches the server.

Spy when you want to synchronise on a real call or verify the payload the app sent. Stub when you need a state the backend will not reliably give you: an error, an empty list, a thousand rows, a slow response.

cy.intercept('POST', '/api/orders').as('create');
cy.get('[data-cy=submit]').click();
cy.wait('@create').then(({ request, response }) => {
  expect(request.body).to.deep.include({ sku: 'A-1', qty: 2 });
  expect(request.headers).to.have.property('authorization');
  expect(response.statusCode).to.eq(201);
});

Two things to watch: cy.wait('@alias') yields the first matching call, so for repeated requests you either wait multiple times or use cy.get('@create.all'); and interception matching is order-sensitive, with later definitions taking precedence.

cy.fixture('orders.json') loads a file from cypress/fixtures; cy.intercept('/api/orders', { fixture: 'orders.json' }) serves it as the response.

The liability is drift: once every test asserts against a hand-written fixture, a backend field rename breaks production while the suite stays green. Mitigations that work in practice — generate fixtures from a real recorded response and refresh them periodically, validate fixtures against the API's schema in CI, and always keep at least one unstubbed end-to-end path per critical flow.

cy.request() makes an HTTP call from the Node process — it bypasses the browser entirely, ignores CORS, and does not involve your application. It is the tool for setup, teardown and pure API assertions.

cy.intercept() observes or replaces calls the application makes.

cy.request('POST', '/api/orders', { sku: 'A-1' })
  .its('body.id')
  .then(id => cy.visit(`/orders/${id}`));

Note that cy.request automatically fails the test on a non-2xx status unless you pass failOnStatusCode: false, which you need when deliberately testing an error response.

For a modest set of endpoint checks alongside a UI suite, yes — cy.request plus Chai assertions is perfectly workable and you keep one report and one CI job.

As a primary API-testing platform it is a poor fit: you are booting a browser to make HTTP calls, there is no native schema-contract workflow, and the runtime cost per test is high compared with a plain HTTP test runner. Most teams keep Cypress for the browser and run API regression separately.

let calls = 0;
cy.intercept('GET', '/api/search*', req => {
  calls += 1;
  if (calls === 1) req.reply({ statusCode: 429, headers: { 'retry-after': '1' }, body: {} });
  else req.continue();
}).as('search');

cy.get('[data-cy=search]').type('invoice{enter}');
cy.contains('Too many requests').should('be.visible');
cy.wait(1100);                       // the Retry-After the API asked for
cy.get('[data-cy=retry]').click();
cy.get('[data-cy=result]').should('have.length.greaterThan', 0);

This is a case where a numeric wait is defensible: you are honouring a contract value the server returned, not guessing at rendering speed.

Block or stub them at the network layer. cy.intercept with { statusCode: 204, body: '' } for the script URL, or use the blockHosts config option to drop entire domains for the whole run.

Two benefits beyond stability: page loads get noticeably faster, and you stop polluting real analytics with test traffic. Keep one dedicated test that does load the widget if its presence is a genuine requirement.

cy.session(key, setupFn) runs the setup once, caches the resulting cookies, local storage and session storage, and restores them for every later test that requests the same key — including across spec files when cacheAcrossSpecs is set.

cy.session([email, role], () => {
  cy.request('POST', '/api/login', { email, password })
    .then(({ body }) => window.localStorage.setItem('token', body.token));
}, { validate: () => cy.request('/api/me').its('status').should('eq', 200) });

The validate option matters: without it a cached-but-expired session silently produces logged-out tests. With it, Cypress re-runs setup when validation fails.

Cypress exposes cy.setCookie, cy.getCookie, cy.clearCookies, and cy.clearLocalStorage; local storage itself is reachable via cy.window().its('localStorage') or directly inside a cy.then.

Typical uses: dismissing a cookie-consent banner by pre-setting its cookie so every test does not start by clicking it, and enabling a feature flag for one spec. With test isolation on, these must be set in beforeEach (or inside cy.session), because everything is cleared between tests.

The restriction comes from the in-browser architecture: the runner and the app share a browser context, and same-origin policy applies to it.

Current Cypress provides cy.origin(), which runs a block of commands in the context of another origin:

cy.origin('https://auth.example.com', { args: { email } }, ({ email }) => {
  cy.get('#email').type(email);
  cy.get('#next').click();
});

Two practical constraints: the callback is serialised, so it cannot close over outer variables (pass them via args), and custom commands are not available inside unless you re-register them. For routine tests, skipping the third-party screen by seeding a session is still faster.

Test the contract rather than the tab. Practical approaches:

• Assert the link's target and href, then visit that URL directly in the same tab.
• Remove the target before clicking: cy.get('a').invoke('removeAttr', 'target').click().
• Stub window.open with cy.stub and assert it was called with the expected URL.

Be explicit in the interview that this is a workaround: you are verifying the application's intent, not the browser's tab behaviour. If genuinely multi-tab interaction is core to the product, that is a legitimate reason to choose a different tool for those specific tests.

There is no first-class frame locator. You reach into the frame's document yourself:

cy.get('iframe[title="Card"]')
  .its('0.contentDocument.body').should('not.be.empty')
  .then(cy.wrap)
  .find('#card-number').type('4242424242424242');

Caveats: the frame must be same-origin or the document is inaccessible; you must wait for the frame to actually load before wrapping; and the wrapped body does not get Cypress's usual retry behaviour on the initial access. Many teams use the cypress-iframe plugin to hide this boilerplate, or stub the payment provider entirely and test the card form separately.

Component testing mounts a single React/Vue/Angular/Svelte component in the real browser with the same command API, no server required. You get real rendering and real events without the cost of a full app boot.

Use it for the layer below your journeys: form validation, conditional rendering, prop and state permutations, edge cases in a data table, accessibility of a single control. Keep E2E for the flows that only break when routing, auth and the backend meet. The practical effect is a much smaller, faster E2E suite.

Cypress does not need a heavy Page Object layer — custom commands and small helper modules usually serve better. A structure that works:

• cypress/e2e/ grouped by user journey, not by page.
• cypress/support/commands.js — cross-cutting commands (login, seed, apiCreateOrder) with TypeScript declarations.
• cypress/fixtures/ — small, refreshed, schema-validated.
• Selector constants co-located with the feature rather than a global selectors file that becomes a dumping ground.

Conventions to enforce in review: no fixed cy.wait(ms), no force: true without a comment, and setup through API rather than UI wherever the UI is not the thing under test.

cypress run executes headlessly and records video by default. Use the official cypress/included Docker image or the setup action to get the required system libraries.

First-time failures, in rough order of frequency: the app under test is not up yet (fix with start-server-and-test or a health-check wait); missing OS dependencies for the browser; the default 1000×660 headless viewport differing from the developer's screen so responsive layouts change; and time-zone differences producing date mismatches.

Cypress parallelises at the spec file level across machines, coordinated by a recording service (Cypress Cloud or a compatible alternative) that hands each machine the next spec based on previous durations.

The consequence for design: one enormous spec file cannot be split, so it becomes the critical path and caps your total speedup. Keeping specs roughly balanced in duration matters more than having few files. Without a coordination service you can still shard manually by passing different --spec globs to each machine, but you lose duration-based balancing.

By default: a screenshot at the moment of failure, and a video of the entire spec in cypress run. Both should be uploaded from CI unconditionally.

The most useful diagnostic is the command log embedded in the video, which shows exactly which command failed and what came before it. Add cy.screenshot() at meaningful checkpoints for long journeys, and disable video for stable suites where the storage cost outweighs the value.

• Time-travel in the runner — hover any command in the log to see the DOM snapshot at that moment. This is the single most useful feature.
• .debug() — pauses and exposes the current subject in the console.
• cy.pause() — halts the queue so you can step command by command.
• debugger inside a .then() — a real breakpoint, because your code runs in the browser.
• The browser DevTools console, where the last command's subject is available as a variable.

It is almost always shared state. Check, in order: data created by an earlier spec that this one assumes or collides with; a cached cy.session whose validate is missing so it restores an expired login; a feature flag or cookie set in one spec and relied on by another; and a machine-level resource such as a single test account used by two specs in parallel.

Reproduce by running the pair rather than the whole suite, then bisect. The permanent fix is to make each spec create the state it needs with uniquely identified data — not to add ordering constraints, which just push the failure into the future.

Stability before speed, because parallelising an unstable suite just produces failures faster.

Order that tends to pay off: replace UI login with cy.session or API login (usually the single largest time saving); remove fixed cy.wait(ms) calls and replace them with alias waits or retrying assertions; stub or block third-party scripts; move component-level checks out of E2E into component tests; split oversized spec files so parallelisation can actually balance them; and only then add machines.

When the requirement collides with the architecture rather than the API: heavy multi-tab or multi-window interaction; genuine Safari/WebKit coverage as a release gate; a large native-mobile surface; a suite dominated by API contract testing; or a need for many browser sessions per test (for example real-time collaboration between two users).

Cypress remains a strong choice where its strengths dominate: fast feedback for front-end teams, excellent debugging, component testing alongside E2E, and a low barrier for developers who already live in the browser.