Cypress Interview Questions and Answers

Cypress is a JavaScript/TypeScript tool for end-to-end and component testing. It runs tests inside the browser, next to the app you are testing.

• Used for UI end-to-end tests, API checks (cy.request), and component tests for React, Vue, Angular and Svelte.
• It comes with its own test runner (a time-travel UI with snapshots), an assertion library (Chai, plus Sinon and jQuery helpers) and automatic waiting.
• It runs on Node.js. Tests are written only in JavaScript or TypeScript.
• It runs without a visible browser in CI with npx cypress run. It runs with a visual window using npx cypress open.

Typical use: a team tests login, checkout or search flows on every pull request. They get screenshots and videos when a test fails.

What they are checking: Whether you know what the tool covers, beyond 'a UI automation tool'

The main difference is where the test code runs. Selenium controls the browser from outside, through the WebDriver protocol. Cypress runs inside the browser, in the same loop as the app.

Choose Cypress for fast, developer-friendly front-end testing of a web app. Choose Selenium when you need many languages, real cross-browser coverage or multi-window flows.

What they are checking: Whether you can compare by architecture and trade-offs, not just say 'Cypress is faster'

Prefer selectors that survive UI changes and show intent.

• Best: special test attributes such as data-cy, data-testid or data-test.
• Good: accessible roles and text, using cy.contains('button', 'Sign in') (or testing-library's findByRole through @testing-library/cypress).
• Avoid: long CSS or XPath chains (div > div:nth-child(3) > span). Also avoid class names made up by CSS-in-JS tools, and indexes that depend on order.

cy.get('[data-cy="email"]').type('[email protected]');

Agree on the data-cy rule with developers. Add the attributes during code review. The official Cypress best practices guide suggests this. Tests then do not break when the styling changes.

What they are checking: Whether you think about keeping tests easy to maintain

A login test with stable selectors, a stubbed failure, and an assertion on the result.

cy.request() sends an HTTP request straight from Cypress, without the browser UI. Use it for API tests, for setting up and removing test data, and for fast login. It shares cookies with the browser.

Each command in a chain passes a subject to the next command. Take cy.get('.row').find('a').click(). get gives the matched row elements. find searches inside them and gives the links. click acts on that subject.

Main defaults:

• defaultCommandTimeout: 4000 ms (queries and assertions)
• pageLoadTimeout: 60000 ms (cy.visit)
• requestTimeout: 5000 ms (waiting for a request in cy.wait('@alias'))
• responseTimeout: 30000 ms (cy.request and waiting for a response)
• execTimeout and taskTimeout: 60000 ms

.should() retries. .then() runs once.

• .should('have.text', 'Paid') or .should(($el) => { ... }) re-runs the earlier query and the assertion until it passes or times out.
• .then(($el) => { expect(...) }) gets the subject at that moment. If the page has not updated yet, the assertion fails at once.

• cy.get(selector) searches the whole document (or the current root) and starts a chain.
• .find(selector) searches only inside the children of the previous subject. It needs a subject.
• cy.contains(text) finds an element by its text. It prefers the deepest element that holds the text. cy.contains(selector, text) narrows it by selector.

Fixtures are fixed data files (usually JSON) in cypress/fixtures. They keep test data out of specs.

Add the command in cypress/support/commands.ts. Also declare its type, so the editor and compiler know about it.

Test retries run a failed test again by themselves, a set number of times, before reporting failure.

Cypress uses the Mocha structure: describe, it, and the hooks before, beforeEach, afterEach, after.

Upload: use .selectFile() (built in since Cypress 9.3).

Before actions like click or type, Cypress waits until the element is:

• visible (not display: none or zero size)
• not disabled
• not detached from the DOM
• not covered by another element at its click point
• scrolled into view and not moving

Honest limits I would name:

After npm install cypress --save-dev and the first npx cypress open, you get:

Cypress accepts alert and confirm dialogs by itself (it clicks OK). It also listens to them through window events. So you check the message instead of clicking.

• Screenshots: taken by themselves when a test fails in cypress run. Add your own with cy.screenshot().
• Videos: turn them on with video: true in the config (off by default in recent versions). They are useful to attach when a test fails.
• Reports: use Mocha reporters. Common choices are mochawesome (HTML/JSON) and cypress-junit-reporter, or the built-in junit reporter for CI dashboards.

Retry-ability means Cypress keeps re-running a query and the assertions after it. It stops when they pass or when the command timeout (4 seconds by default) ends.

• Retried: queries such as get, find, contains, its, invoke (read-only), eq, filter, and the assertions chained after them (.should, .and).
• Not retried: actions such as click, type, check, select, and .then() callbacks. Actions do wait until the element is ready (visible, not covered, not disabled, not moving) but they run once.

// Retries the whole chain until the list has 3 items
cy.get('.todo').should('have.length', 3);
// Anti-pattern: assertion inside .then does not retry
cy.get('.todo').then(($els) => expect($els.length).to.eq(3));

Since Cypress 12, the whole chain of queries before the assertion is run again. This fixes stale-element problems. A good rule: put what you wait for in a .should. Do not use .then. Do not use a fixed cy.wait(2000).

What they are checking: Whether you know why Cypress tests are stable and what breaks that

cy.intercept(method, url, response?) matches requests at the proxy. With no response, it only watches (spy). With a fixed response or a handler, it replaces the real reply (stub).

// Spy and wait
cy.intercept('GET', '/api/orders*').as('orders');
cy.visit('/orders');
cy.wait('@orders').its('response.statusCode').should('eq', 200);

// Stub with a fixture
cy.intercept('GET', '/api/orders*', { fixture: 'orders.json' });

// Force an error to test the UI
cy.intercept('POST', '/api/orders', { statusCode: 500, body: { message: 'Server error' } });

// Modify the real response
cy.intercept('GET', '/api/user', (req) => {
  req.continue((res) => { res.body.plan = 'pro'; });
});

Register the intercept before the action that triggers it. Use stubs for error, empty, slow (delay) and rare states that are hard to get with real data. Keep a few tests without stubs to prove the real systems work together.

What they are checking: A core Cypress strength: control of network state

cy.session(id, setup, options) saves and restores cookies, localStorage and sessionStorage between tests. So you log in once, not in every test.

Cypress.Commands.add('loginBySession', (user: string, pass: string) => {
  cy.session(['login', user], () => {
    cy.request('POST', '/api/login', { email: user, password: pass });
  }, {
    validate() {
      cy.request('/api/me').its('status').should('eq', 200);
    },
    cacheAcrossSpecs: true,
  });
});

beforeEach(() => { cy.loginBySession('[email protected]', 'secret'); cy.visit('/'); });

Key points:

• The id (plus args) names the saved session. Use a different id for each role.
• validate runs the setup again if the session has expired.
• Test isolation is on by default since Cypress 12. The page and storage are cleared before each test. So cy.session is the supported way to keep a login.
• Visit a page after restoring. The restore step leaves a blank page.

What they are checking: Knowing how to make logins faster in modern Cypress

Cypress has two parts: a Node.js process and the browser.

Cypress commands do not return promises that give you values. They add work to an internal command queue and return a chainable object. The queue runs later, after your spec function has finished.

Page objects wrap UI steps in classes. App actions skip the UI and set the state directly (an API call, a store update, a cookie).

Cypress has no built-in iframe command. But you can reach the iframe's document yourself.

Keep settings out of specs and secrets out of git.

By default, Cypress allows one superdomain per test. Say a flow leaves it, for example login on auth.example.com and then back to app.example.com. Then the commands on the other origin must run inside cy.origin().

Component testing mounts one component in the real browser with Cypress. It tests that component alone, without the whole app or the backend.

cy.task(name, arg) calls a Node.js function that you define in setupNodeEvents in the config. Use it for anything the browser cannot do: adding data to a database, reading files, sending emails, calling internal services.

Use cy.clock() to freeze or control time. Use cy.tick() to move it forward. This replaces real waiting.

There is no single best tool. Pick by your constraints.

• Selenium: the widest language and browser support (including real Safari and old browsers). It has a huge ecosystem. But you build the waits, runner, reporting and parallel runs yourself.
• Cypress: the best developer experience for front-end teams. It has time-travel debugging, automatic retries and built-in network stubbing. Limits: JavaScript/TypeScript only, one tab per test, cross-origin needs cy.origin, and parallel runs are easiest with Cypress Cloud.
• Playwright: many languages (JS/TS, Python, Java, .NET). It supports Chromium, Firefox and WebKit, multiple tabs and contexts, built-in parallel runs and tracing, and free sharding (splitting tests across machines).

For a new JS/TS web project I would pick Playwright and Cypress as the two finalists. Then I would run a one-week trial on the three hardest flows (login with SSO, file upload, multi-tab). If the app needs multi-tab or multi-user flows, or testers who do not write JS, Playwright wins. If the team is front-end heavy and likes component testing and the interactive runner, Cypress is a good fit.

What they are checking: Decisions based on trade-offs and a test plan, not loyalty to one tool

A fixed cy.wait(5000) is a guess. It is too short on a slow day and wastes time on a fast day. cy.wait('@alias') waits exactly until one request finishes, then goes on at once.

Fix for the unstable table test (it passes sometimes and fails other times):

cy.intercept('GET', '/api/customers?*').as('getCustomers');
cy.visit('/customers');
cy.wait('@getCustomers');
cy.get('[data-cy="row"]').should('have.length.greaterThan', 0);

Steps I would take:

1. Find the request that fills the table. Give it an alias before you open the page.
2. Wait for the alias. Then assert on the DOM, so Cypress retries until the page has finished drawing.
3. If the page shows a spinner, assert cy.get('[data-cy=spinner]').should('not.exist').
4. Remove all fixed waits. Keep one only when there is no signal to watch, and add a comment to say why.

What they are checking: Replacing sleeps with waits that give the same result every time

Treat login as setup, not as the thing you test. Test the login form in one or two special specs. Skip it everywhere else.

1. Log in with cy.request to the auth endpoint, which sets the cookie. Or put the token in localStorage.
2. Wrap it in cy.session, so it is saved across tests and specs.
3. Add a validate step, so an expired session logs in again by itself.
4. Use one test user per role, with known data. Create them with a seed script or an API.

cy.session('admin', () => {
  cy.request('POST', '/api/auth', { user: 'admin', pass: Cypress.env('ADMIN_PASS') })
    .then(({ body }) => window.localStorage.setItem('token', body.token));
});
cy.visit('/dashboard');

This usually saves several seconds per test. It also removes a common cause of unstable tests. Keep passwords in environment variables or CI secrets, never in the repo.

What they are checking: Practical ways to make a test suite faster

Work from evidence, not guesses.

1. Reproduce: run without a visible browser, in the same browser and screen size as CI. Run the single test in a loop (--spec and a repeat loop) to measure how often it fails.
2. Read the artifacts: failure screenshot, video, Cypress Cloud or console logs, and the network log. Use the time-travel snapshots in cypress open.
3. Find the type of cause:
   • Timing: asserting before data loads, fixed waits, animations. Fix with cy.intercept aliases and a retrying .should.
   • Shared state: tests depend on order or leftover data. Make each test add and clean its own data.
   • Selectors: changing classes, duplicate elements, detached DOM.
   • Environment: slower CI, different data, third-party scripts.
4. Fix the root cause. Do not just add retries. Use retries: { runMode: 2 } only as a safety net, and track retried tests as unstable.
5. If a test cannot be fixed quickly, quarantine it (tag it, or skip it with a ticket). Then it does not block the pipeline.

What they are checking: A clear method for unstable tests, the most common QA automation question

Run without a visible browser, with a fixed Node and Cypress version and a built app.

I compare environment, timing and data, in that order.

Measure first, then remove waste.

No. Cypress controls a single tab and cannot switch to a new one. Common workarounds:

• Remove the target attribute so the link opens in the same tab:

Conditional testing means choosing a path based on the current DOM (if element exists, click it). It is discouraged because the DOM changes over time. Checking at one moment creates a race condition. The test then gives different results on different runs.