Cypress Interview Questions and Answers (2026)

TL;DR

Strong Cypress interview answers connect API knowledge to test design. Be ready to explain command queuing, retry-ability, subject management, network control, test isolation, sessions, custom commands, component testing, and parallel CI with accurate examples.

Key Takeaways

• Explain Cypress through its browser execution model, command queue, automatic retry behavior, and test isolation.
• Separate queries, assertions, and non-query commands when reasoning about retries and flakiness.
• Use cy.intercept for browser traffic, cy.request for direct HTTP setup or checks, and know that cy.request bypasses intercept routes.
• Design stable tests around observable user behavior, accessible selectors, deterministic data, and event-based synchronization.
• Discuss tradeoffs honestly, including multi-tab limitations, browser scope, backend coverage, and Cloud-dependent orchestration.
• Answer senior questions with a diagnosis method, an architectural boundary, and a concrete code-level example.

The best cypress interview questions and answers test whether you can reason about Cypress, not whether you memorized a list of commands. A strong candidate explains when Cypress retries, where code executes, how browser traffic is controlled, and how to keep a suite reliable in CI.

This guide covers foundational, experienced, and scenario-based questions for 2026. The examples use current Cypress APIs and TypeScript. Treat each model answer as a structure you can adapt to your own project evidence, because interviewers usually probe the decisions behind the syntax.

TL;DR

1. Core Cypress Interview Questions and Answers

Cypress is a JavaScript and TypeScript testing tool for browser-based end-to-end and component tests. Its test code coordinates with the browser while Cypress controls execution, captures commands, retries eligible queries, and presents a time-travel-style Command Log. The useful interview point is not that Cypress is fast or easy. It is that its execution model gives the runner direct visibility into the application and browser lifecycle.

When asked why a team might choose Cypress, connect the choice to constraints. Cypress provides automatic waiting for retriable command chains, network interception, screenshots and videos in CI, component testing adapters, and a cohesive debugging experience. It fits web teams that want strong frontend feedback and write automation in JavaScript or TypeScript.

Also name boundaries. Cypress is not a general desktop automation tool. A test normally works in one browser tab, and native browser windows require a different strategy. Mobile web can be checked with viewport and supported browser coverage, but Cypress is not native mobile application automation. Backends still need API, contract, integration, security, and performance testing outside the browser suite.

A balanced answer sounds senior because it maps the tool to the test problem. If the interviewer asks for a comparison, use Selenium vs Cypress for test automation to rehearse differences in language support, browser control, ecosystem, and debugging.

2. Explain the Command Queue and Asynchronous Execution

Cypress commands do not behave like immediately resolved JavaScript values. Calls such as cy.get(), .click(), and cy.request() enqueue work. Cypress starts executing that queue after the test function finishes building it. This is why assigning a Cypress chain to a variable and expecting a synchronous DOM element is incorrect.

it('shows the signed-in user', () => {
  cy.visit('/account')

  cy.get('[data-cy=display-name]').then(($name) => {
    const text = $name.text().trim()
    expect(text).to.eq('Avery QA')
  })
})

The callback passed to .then() runs when the preceding command resolves. A returned Cypress chain is incorporated into the queue. Cypress commands are thenable in Cypress's controlled chain, but they are not ordinary promises and should not be wrapped casually in async and await.

Plain JavaScript runs immediately while the test is being defined. That distinction explains a classic surprise:

let label = 'before'

cy.get('[data-cy=status]').then(($status) => {
  label = $status.text()
})

cy.then(() => {
  expect(label).to.eq('Ready')
})

The final assertion must also be queued. In an interview, explain the sequence rather than saying Cypress is asynchronous. Mention that aliases, closures, and .then() are subject-access tools, while chaining is usually clearer than external mutable variables.

3. Queries, Assertions, Actions, and Retry-Ability

Cypress retry-ability is central to reliable answers. Queries such as cy.get() and .find() link with assertions and retry from the beginning of the linked query chain until the assertions pass or the command times out. Assertions such as .should() are queries for retry purposes. A non-query command, including an action like .click(), executes once after its built-in actionability checks succeed.

cy.get('[data-cy=results]')
  .find('[data-cy=result-row]')
  .should('have.length', 3)
  .first()
  .should('contain.text', 'Payment accepted')

If the list initially has one row and later has three, Cypress retries the query chain. It does not need cy.wait(2000). This automatic retry is not the same as rerunning a failed test. Test retries rerun the whole test according to configuration, while command retry-ability repeatedly evaluates eligible commands within one attempt.

.then() is not retried, so use .should(callback) when the callback contains assertions that should be reevaluated. Keep a .should() callback free of side effects because it may execute multiple times.

cy.get('[data-cy=total]').should(($total) => {
  const amount = Number($total.text().replace('
#39;, ''))
  expect(amount).to.be.greaterThan(0)
})

An experienced answer also mentions actionability. Before clicking, Cypress checks conditions such as visibility, coverage, disabled state, and animation. Forcing an action can bypass useful user-like checks, so { force: true } should be a documented exception, not a default flake fix.

4. Selectors, Subjects, and Scoped Queries

Stable selectors express intent and resist layout changes. Prefer accessible queries when the visible role or label is part of the product contract, and use dedicated attributes such as data-cy for elements without a stable semantic handle. Avoid long CSS paths, framework-generated classes, and positional selectors tied to incidental markup.

cy.contains('button', 'Create account').click()

cy.get('[data-cy=profile-form]').within(() => {
  cy.get('input[name=email]').type('candidate@example.test')
  cy.contains('button', 'Save').click()
})

The current subject flows through a command chain. cy.get() starts a query from the document, while .find() searches descendants of the current subject. .within() scopes commands in its callback, but it is unsafe to rely on changing the subject by returning a different element from that callback. .wrap() introduces a value or jQuery element into a Cypress chain.

When asked whether test IDs are bad, reject the absolute framing. A test ID is valuable when it represents a stable automation contract. A role, label, or user-visible text is stronger when changing that value should fail the test. The team can define a selector policy: use accessible semantics first for user-facing controls, explicit test attributes for ambiguous widgets, and domain-level helper functions to prevent selector duplication.

Do not hide every selector in a page object automatically. Page objects can centralize behavior, but oversized classes often conceal assertions and create brittle inheritance. Small screen helpers, app actions, and typed domain functions may be easier to maintain.

5. Network Spying, Stubbing, and Request Assertions

cy.intercept() observes or controls browser network traffic. Register it before the application action that sends the request, apply an alias, trigger the action, and wait for that alias. A handler is optional for a spy and required when the test changes or supplies a response.

type CreateOrder = { sku: string; quantity: number }
type CreatedOrder = { id: string; status: 'created' }

it('submits an order', () => {
  cy.intercept<CreateOrder, CreatedOrder>('POST', '/api/orders')
    .as('createOrder')

  cy.visit('/checkout')
  cy.get('[data-cy=quantity]').clear().type('2')
  cy.contains('button', 'Place order').click()

  cy.wait('@createOrder').then(({ request, response }) => {
    expect(request.body).to.include({ quantity: 2 })
    expect(response?.statusCode).to.eq(201)
    expect(response?.body.status).to.eq('created')
  })

  cy.contains('Order confirmed').should('be.visible')
})

For deterministic frontend states, pass a StaticResponse with statusCode, body, headers, fixture, delay, or forceNetworkError as appropriate. Use req.reply() for a dynamic stub and req.continue() to reach the server and optionally inspect its response. Normal intercept routes match in reverse definition order, except { middleware: true } routes, which run first in definition order.

Important interview trap: cy.request() sends a direct HTTP request outside the browser and bypasses routes defined by cy.intercept(). Use it for API-assisted setup, cleanup, and backend assertions, but do not expect an intercept alias to capture it. The Cypress cy.intercept examples guide is useful practice for route matchers and response control.

6. Fixtures, Test Data, and Isolation

Fixtures are static files loaded with cy.fixture() or served through the fixture property of an intercept response. They are useful for readable, version-controlled test payloads. They are not a complete data strategy because shared server records, generated identities, and cleanup still need ownership rules.

beforeEach(() => {
  cy.intercept('GET', '/api/plans', {
    fixture: 'plans/active-plans.json',
  }).as('getPlans')
})

Test isolation resets browser context before each test when enabled, clearing the page and browser storage state. Cypress also clears aliases, intercepts, spies, stubs, and clock changes between tests. Tests must not depend on execution order or state left by a previous it block.

Reliable data patterns include creating a unique record through cy.request(), using an idempotent test-support API, assigning a tenant per CI worker, and deleting only records owned by the test. Cleanup should tolerate partial failures and must not erase data belonging to another worker. Timestamp-only names can collide under parallel load, so combine a build identifier, worker identifier, and random suffix when uniqueness matters.

For stubbed browser tests, keep fixtures synthetic and free of production personal data. Verify response shapes at the API or contract layer so a fixture does not drift silently from the real service. A senior answer makes the boundary explicit: the stubbed test proves UI behavior for a supplied contract, while a non-stubbed path proves integration.

7. Hooks, Configuration, and Environment Boundaries

Use beforeEach for repeatable per-test setup, such as registering intercepts or creating isolated data. Use before only when state is safe to share and a later test does not require a previous test's success. Most login and navigation belongs in beforeEach, possibly accelerated with cy.session().

Configuration lives in cypress.config.ts, where defineConfig() provides typing. End-to-end Node events are registered in setupNodeEvents.

import { defineConfig } from 'cypress'

export default defineConfig({
  e2e: {
    baseUrl: 'http://localhost:3000',
    retries: {
      runMode: 2,
      openMode: 0,
    },
    setupNodeEvents(on, config) {
      on('task', {
        log(message: string) {
          console.log(message)
          return null
        },
      })

      return config
    },
  },
})

Browser commands cannot directly use arbitrary Node modules or a database driver. cy.task() crosses to the Node process for approved operations registered under the task event. A task must end and return a serializable value, null, or a promise resolving to one. Returning undefined is treated as an error because it often signals an unhandled task.

Keep secrets in CI secret storage or protected environment configuration. Do not expose credentials through Cypress.env() values that are bundled or logged unnecessarily. Test-support endpoints must be inaccessible in production and should preserve the real authorization model rather than inventing client-side bypass flags.

8. Authentication and cy.session Design

cy.session() caches and restores cookies, local storage, and session storage for a deterministic ID. The setup callback establishes the session, and validate proves restored state is still correct. The ID must distinguish every factor that changes the resulting session, such as user, role, tenant, or login strategy.

function loginAs(email: string, role: 'member' | 'admin') {
  return cy.session(['api-login', email, role], () => {
    cy.request({
      method: 'POST',
      url: '/test-support/login',
      body: { email, role },
    }).its('status').should('eq', 204)
  }, {
    validate() {
      cy.request<{ email: string; role: string }>('/api/me')
        .its('body')
        .should('include', { email, role })
    },
  })
}

beforeEach(() => {
  loginAs('admin@example.test', 'admin')
  cy.visit('/admin')
})

Session restoration does not restore a page, and test isolation can leave a blank page. Visit the intended route after the helper. Validation should be fast, idempotent, and specific. Cookie existence alone can accept an expired token or the wrong user; a protected identity endpoint is stronger.

cacheAcrossSpecs: true can share a session among specs on the same machine within one run. It does not create one global cache across separate CI machines. Backend data also remains outside the browser snapshot, so tests still need isolated accounts and state. Review practical Cypress cy.session examples for role and tenant patterns.

9. Component Testing Versus End-to-End Testing

Cypress component tests mount a component in a real browser with a framework-specific adapter. End-to-end tests visit a running application and exercise deployed boundaries. The choice should follow the risk and feedback need, not a target percentage.

import { mount } from 'cypress/react18'
import { SaveButton } from './SaveButton'

it('disables saving while a request is pending', () => {
  mount(<SaveButton pending onSave={() => undefined} />)
  cy.contains('button', 'Saving').should('be.disabled')
})

Use the mount function for the framework adapter installed in the project, because React, Vue, Angular, and other integrations differ. Production providers, routing, themes, and state containers often belong in a shared custom mount command.

A good test portfolio pushes detailed view-state combinations into component tests, validates services through API and contract suites, and retains a small set of critical end-to-end journeys. Avoid duplicating the same assertions at every layer. The interview answer should emphasize evidence coverage and diagnostic speed.

10. Cypress Framework Interview Questions for Maintainability

A maintainable Cypress framework is a small set of explicit conventions, not a deep class hierarchy. Organize specs around business capabilities, centralize only repeated behavior, keep assertions near the scenario, and make test data ownership visible. Add typed API clients or domain helpers when they reduce duplication without hiding Cypress's command flow.

Custom commands are appropriate for broadly reused, Cypress-shaped operations such as authentication or a stable domain action. Overwriting built-in commands should be rare because it changes behavior every test author expects. Type custom commands through the Cypress namespace and return the chain.

declare global {
  namespace Cypress {
    interface Chainable {
      createProject(name: string): Chainable<Response<{ id: string }>>
    }
  }
}

Cypress.Commands.add('createProject', (name: string) => {
  return cy.request<{ id: string }>({
    method: 'POST',
    url: '/api/projects',
    body: { name },
  })
})

Plain functions are often preferable because normal imports, parameters, and TypeScript inference are simple. Do not turn every two-line interaction into a command. A helper should preserve the important actions and failures in the Command Log.

Framework governance also includes linting, formatting, focused pull request checks, ownership for flaky tests, artifact retention, dependency updates, and a documented selector contract. Metrics should support decisions. Track duration distribution, retry results, quarantined tests, and failure causes, but never turn a green rate into an incentive to suppress legitimate failures.

11. CI, Parallelization, and Flake Triage

cypress run executes specs headlessly by default. Cypress Cloud parallelization requires recorded runs and multiple CI machines or containers. Each machine starts the same command with --record --parallel and joins the same build. Cypress Cloud assigns spec files based on recorded duration history, so parallelization is file-based and execution order is not guaranteed.

npx cypress run \\
  --record \\
  --parallel \\
  --group chrome-e2e \\
  --browser chrome \\
  --ci-build-id \"$GITHUB_RUN_ID-$GITHUB_RUN_ATTEMPT\"

The record key belongs in CI secrets, commonly exposed as CYPRESS_RECORD_KEY, not committed in the command. Most supported CI providers supply an automatically recognized build identifier, so pass --ci-build-id only when the default is missing or unsuitable. Every worker joining one parallel group must discover the same spec list and use compatible Cypress configuration.

Test retries can identify intermittent failures and collect another attempt, but retries are not a fix. Triage the first failed attempt, classify product, test, data, environment, or infrastructure causes, and preserve screenshots, videos, network evidence, and application logs. Replace arbitrary sleeps with observable readiness. Fix selector ambiguity, isolate worker data, and make backend preconditions deterministic.

Manual CI sharding with --spec is possible without Cloud, but the pipeline owns partition balance, reporting, and empty-shard handling. Be explicit about that tradeoff rather than calling any concurrent jobs Cypress load balancing.

12. Scenario-Based Cypress Interview Questions and Answers

Q: A test passes locally but times out in CI. What do you inspect first?

I inspect the earliest command that diverged, its screenshot or video, and the application and network events around it. I compare browser, viewport, environment data, CPU pressure, and configuration, then replace timing assumptions with a specific UI or request condition. I do not begin by increasing every timeout.

Q: An intercept alias never resolves. How do you debug it?

I confirm the intercept is registered before the request, then compare the actual method, hostname, pathname, and query with the matcher. I check whether the browser cache or a service worker prevented a network request and whether another overlapping route consumed it. I narrow the matcher rather than using **/*.

Q: How would you test a loading spinner?

I stub the relevant request with a small controlled delay, visit or trigger the action, assert the spinner is visible, wait on the alias, then assert it disappears and content renders. The delay exposes a state; it is not a performance benchmark.

Q: How do you test a new tab link?

If the requirement is the link contract, I assert its href and target. If I need to exercise the destination in the same tab, I can remove target before clicking, provided that change matches the scope of the test. I do not pretend Cypress is controlling two independent tabs.

Q: How do you reduce a 90-minute suite?

I profile spec and hook duration, remove duplicated UI setup through APIs or validated sessions, move detailed rendering cases down to component tests, and isolate expensive data creation. Then I split oversized specs and add the right number of parallel workers. I monitor the slowest worker and service capacity, because worker count alone does not guarantee a shorter run.

Q: A click needs { force: true }. What does that tell you?

It tells me Cypress's actionability checks found the element hidden, covered, disabled, animating, or otherwise unsuitable. I inspect the DOM and visual state to decide whether this is a product defect, the wrong selector, or an intentional hidden control. I use force only when bypassing actionability is the test's explicit purpose.

Q: When would you avoid stubbing?

I avoid stubbing when the test's purpose is to prove the deployed browser-service contract, authentication integration, or a critical backend outcome. I may spy on the real call for synchronization and keep assertions resilient to shared data. Detailed error and edge-state rendering can remain stubbed elsewhere.

Q: How do you handle an iframe?

I first determine whether it is same-origin and whether the feature can be validated through a supported component or API boundary. Same-origin iframe DOM can be reached with a carefully implemented helper that retries until the document is ready. Cross-origin embedded content has browser security constraints, so I validate the integration contract and use the provider's supported test approach rather than fragile DOM access.

Interview Questions and Answers

Q: Why are Cypress commands not ordinary promises?

Cypress queues commands and controls their execution, subjects, logging, timeouts, and retry behavior. That contract is different from a promise that starts work immediately. I use chains, .then(), aliases, and cy.wrap() instead of applying async and await indiscriminately.

Q: What is the difference between .should() and .then()?

.should() assertions participate in retry-ability, and its callback may execute several times. .then() runs once after the prior command resolves and is better for transformations or one-time logic. Side effects do not belong in a retried .should() callback.

Q: Does Cypress retry a click until the next page appears?

No. Cypress retries queries and actionability checks leading up to the click, then performs the action once. Assertions after the click can retry their linked queries. If the click legitimately does not register, I investigate the application event instead of relying on repeated clicks.

Q: What does test isolation reset?

With test isolation enabled, Cypress resets the browser context before each test and clears Cypress-managed state such as aliases, intercepts, spies, stubs, and clock changes. Tests should create their own server state as well, because browser isolation does not roll a database back.

Q: What is the difference between cy.intercept() and cy.request()?

cy.intercept() observes or changes requests made by the application in the browser. cy.request() sends an HTTP request directly from Cypress for setup or verification and bypasses intercept routes. I choose based on whether I am testing browser behavior or calling the service directly.

Q: How do you validate a cached session?

I call a fast protected identity endpoint and assert the expected user, tenant, or permission. A cookie-exists check is too weak because a cookie may be expired or belong to the wrong context. Validation must be idempotent because it can run whenever Cypress restores the session.

Q: Are fixed waits always wrong?

A fixed wait is usually wrong when it guesses how long an observable event will take. I wait on an alias, a retriable DOM state, or another explicit readiness signal. A controlled wait may be relevant when time itself is the requirement, though cy.clock() and cy.tick() are often more precise for application timers.

Q: How do you test uncaught exceptions?

I allow unexpected application exceptions to fail tests because they are useful defect signals. If one known third-party error must be ignored, I scope the exception handler narrowly to its message and document why. A global handler that always returns false hides real failures.

Q: What belongs in a custom command?

A repeated operation that naturally participates in a Cypress chain and has stable domain meaning can be a custom command. I keep simple utilities as plain functions and avoid commands that obscure key assertions. The command should be typed and return its chain.

Q: How does Cypress Cloud parallelization distribute work?

Workers join the same recorded run and offer the same spec set. Cypress Cloud assigns spec files one at a time using duration history to balance the available machines. It does not split individual tests within one spec, so file boundaries affect utilization.

Q: How do component tests change the test pyramid?

They provide browser-realistic feedback for component states without requiring a full deployed journey. I use them for rendering combinations and interactions, keep service contracts at API layers, and retain critical end-to-end flows. The result is faster diagnosis with less duplication.

Q: What makes a Cypress test deterministic?

It owns its starting data, waits on observable events, uses unambiguous selectors, and does not depend on order or another worker. External services are either controlled at a documented boundary or validated in a dedicated integration path. Retries should reveal residual flake, not define determinism.

Common Mistakes

• Treating Cypress commands as synchronous return values or ordinary promises.
• Using cy.wait(5000) instead of waiting for the state transition that matters.
• Registering cy.intercept() after cy.visit() or after the triggering click.
• Using broad selectors and { force: true } to silence actionability failures.
• Sharing users or mutable records across parallel workers without ownership.
• Putting UI login in every test when an approved API session can create the same state.
• Stubbing every critical path, then claiming the suite validates backend integration.
• Adding whole-test retries without classifying and fixing the original failure.
• Hiding all behavior inside page objects and leaving specs with no readable business intent.
• Committing record keys, passwords, tokens, or production-derived fixtures.

Conclusion

These cypress interview questions and answers cover the knowledge that distinguishes command recall from engineering judgment. Explain the queue and retry model precisely, select the right network and data boundary, and show how isolation, sessions, component tests, and CI orchestration fit together.

Practice each answer with one example from your own work: the failure you diagnosed, the tradeoff you made, and the evidence that improved. That turns a technically correct response into an interviewer-credible SDET answer.

Interview Questions and Answers

Frequently Asked Questions

Related Guides

• Cypress Scenario-Based Interview Questions and Answers (2026)
• Cypress Interview Questions and Answers
• Cypress Interview Questions for 3 Years Experience
• REST Assured Interview Questions and Answers (2026)
• TestNG Interview Questions and Answers (2026)
• Top 50 Playwright Interview Questions and Answers (2026)