Cypress Interview Questions & Answers (2026)

What is Cypress and how does it differ from Selenium?

Cypress is a JavaScript‑based end‑to‑end testing framework that runs directly in the browser, giving it native access to DOM elements and network requests. Unlike Selenium, which drives browsers via WebDriver and runs outside the browser process, Cypress executes in the same run loop, eliminating flakiness caused by network latency and enabling real‑time debugging. Interviewers expect you to highlight its automatic waiting, time‑travel snapshots, and the trade‑off of limited cross‑browser support compared to Selenium’s broader compatibility.

Explain Cypress command chaining and its effect on test readability.

Cypress commands return a chainable object, allowing you to concatenate actions like cy.get().click().should(). This fluent API makes tests read like a narrative, reducing boilerplate and improving maintainability. Each command is enqueued and executed sequentially, so you don’t need explicit callbacks or promises. Interviewers look for awareness that chaining also hides async behavior, so you must avoid mixing Cypress commands with raw promises to prevent race conditions.

cy.get('button').click().should('be.enabled');

How does Cypress handle waiting for elements, and when would you need explicit waits?

Cypress automatically retries assertions until they pass or a timeout expires, eliminating most manual waits. It watches for DOM changes and network activity, re‑querying elements as needed. However, explicit waits (cy.wait()) are justified when dealing with third‑party animations, debounced API calls, or when you need to pause for a known delay. Overusing explicit waits signals a lack of understanding of Cypress’s built‑in retry mechanism, which interviewers often flag.

cy.wait(500); // use sparingly

Explain how Cypress handles asynchronous code and why callbacks are unnecessary.

Cypress queues commands and resolves them internally, abstracting away promises. Each command returns a chainable object, and Cypress waits for the previous command to finish before proceeding. This eliminates the need for explicit callbacks or .then() in most cases, reducing callback hell. Interviewers look for you to mention that you can still use .then() when you need to work with the yielded value, but the framework handles async flow automatically.

What is the purpose of the Cypress ‘support’ file and how would you use it?

cypress/support/e2e.js (or index.js) runs before every spec, allowing you to set global behavior. Common uses include importing custom commands, configuring global exception handling, and adding beforeEach hooks for common setup like login. By centralizing such logic, you avoid repetition and ensure consistent test environment. Interviewers expect you to demonstrate that you keep the support file lean and delegate feature‑specific code to separate modules.

What are the benefits and drawbacks of using data‑test attributes for selectors?

Data‑test attributes provide stable, intention‑revealing selectors that are immune to UI changes, improving test resilience. They separate test logic from presentation, making refactors safe. However, overusing them can clutter markup and may require coordination with developers. Interviewers expect you to balance readability with maintainability, and to mention that fallback to semantic selectors is acceptable when data‑test attributes are unavailable.

Describe how to use fixtures in Cypress and why they are useful.

Fixtures are static files (JSON, CSV, etc.) stored in the cypress/fixtures folder that you can load with cy.fixture(). They provide deterministic data for tests, enabling repeatable scenarios without relying on external APIs. By injecting fixture data via cy.intercept() you can mock responses, isolate front‑end behavior, and speed up test suites. Interviewers expect you to discuss the benefit of decoupling tests from flaky back‑ends and the importance of keeping fixture data realistic.

cy.fixture('user.json').then(user => { cy.intercept('GET /api/user', user); });

What is cy.intercept and how does it differ from cy.route?

cy.intercept replaces the older cy.route API, offering more granular control over network stubbing. It can intercept any HTTP method, match on URL patterns, and modify request or response bodies. Unlike cy.route, which only works with XHR, cy.intercept also handles fetch calls and WebSocket traffic. Interviewers look for you to explain how intercept enables request validation, response mocking, and performance measurement, and why you’d choose it for modern applications.

cy.intercept('POST', '/api/login', { statusCode: 200, body: { token: 'abc' } });

How would you organize a large Cypress test suite for maintainability?

Structure tests by feature or user flow, placing related spec files in dedicated folders. Use custom commands (Cypress.Commands.add) for reusable actions, and page‑object‑like modules to encapsulate selectors. Keep configuration in cypress.config.js, and leverage environment variables for dynamic data. This modular approach reduces duplication, eases onboarding, and allows selective test execution, which interviewers view as a sign of scalable test architecture.

Explain the role of Cypress plugins and give an example of a useful plugin.

Plugins extend Cypress’s core functionality by hooking into the Node process before test execution. They can modify configuration, add tasks, or integrate with external services. A common plugin is cypress-mochawesome-reporter, which generates detailed HTML reports with screenshots. Interviewers expect you to discuss how plugins enable tasks like database seeding via cy.task, and the importance of keeping plugin code side‑effect free to avoid flaky tests.

What strategies would you use to reduce test flakiness in Cypress?

First, rely on Cypress’s automatic retries and avoid hard waits. Second, mock unstable external services with cy.intercept to provide deterministic responses. Third, use data‑test attributes for stable selectors instead of dynamic IDs. Fourth, isolate tests by resetting state (e.g., cy.clearCookies, cy.session) and clean up after each test. Finally, run tests in a headless CI environment with consistent screen resolution. Interviewers look for a systematic approach that addresses both UI and network sources of flakiness.

How do you mock a third‑party API call that uses fetch in Cypress?

Use cy.intercept() to stub the fetch request. Provide a route matcher for the URL and supply a static response object. Because cy.intercept works with both XHR and fetch, no extra setup is required. Example: cy.intercept('GET', 'https://api.example.com/data', { body: { id: 1 } }); This isolates the test from external dependencies, which interviewers consider a best practice for reliability.

How would you test file upload functionality with Cypress?

Use cy.get('input[type=file]').attachFile('sample.pdf') provided by the cypress-file-upload plugin. Ensure the input has the correct selector and that the fixture file exists in cypress/fixtures. After attaching, trigger the form submission and assert the expected server response via cy.intercept. Interviewers look for awareness of the need to install the plugin, configure it in the support file, and handle any asynchronous upload progress indicators.

How can you run Cypress tests in parallel on a CI/CD pipeline?

Use the Cypress Dashboard Service or a self‑hosted parallelization tool. In CI, set the CYPRESS_RECORD_KEY, then invoke cypress run with --record and --parallel flags. The Dashboard splits specs across available containers, balancing load and aggregating results. If you avoid the Dashboard, you can split spec files manually and run them in separate jobs, merging reports afterward. Interviewers expect you to discuss cost, security of the record key, and handling of shared state across parallel jobs.

cypress run --record --parallel

What is the purpose of cy.session and when should you use it?

cy.session caches and restores the state of a logged‑in user across tests, reducing login overhead. It stores cookies, local storage, and session storage after the first execution, then rehydrates them for subsequent tests. Use it when multiple specs require authentication, improving speed and consistency. Interviewers look for you to mention that sessions are scoped per spec file, and that you must clear them when testing logout flows to avoid false positives.

How do you debug a failing Cypress test that passes locally but fails in CI?

First, enable video recording and screenshots in CI to capture the failure state. Compare environment variables, screen resolution, and headless mode differences. Use cy.task to log server responses, and add cy.intercept to verify network calls. Check for timing issues by adding explicit waits temporarily. Finally, run the same spec locally in headless mode to replicate CI conditions. Interviewers expect a methodical approach that isolates environment, network, and timing factors.

Can Cypress test multiple browsers? Explain current limitations.

Cypress officially supports Chrome, Chromium, Edge, and Firefox in recent versions, but Safari support is experimental and limited. Browser-specific features like WebKit APIs may not be fully available, and some Cypress plugins may behave differently across browsers. Interviewers want you to acknowledge the trade‑off: broader cross‑browser coverage versus Cypress’s deep integration with Chrome‑based browsers, and how you might supplement Cypress with other tools for full coverage.

How would you integrate visual regression testing into Cypress?

Add a visual testing plugin such as cypress-image-snapshot. Capture baseline screenshots with cy.matchImageSnapshot() and compare them against new runs. Configure thresholds for pixel differences to tolerate minor rendering changes. Store baselines in version control and run the comparison in CI. Interviewers look for awareness of false positives due to dynamic content, and strategies like masking or using deterministic data to keep snapshots stable.

What are the security considerations when using Cypress in a production-like environment?

Avoid exposing sensitive credentials in test code; use environment variables and Cypress’s secret management. Ensure that cy.request() does not bypass authentication checks unintentionally. When mocking APIs, do not disable SSL verification for real endpoints. Also, limit test access to staging environments that mirror production but isolate data. Interviewers expect you to discuss the principle of least privilege and how to prevent test artifacts from leaking into production logs.

Describe how you would implement a retry mechanism for flaky network requests in Cypress tests.

Leverage cy.intercept() to stub the request and use the ‘times’ option to simulate failures before a successful response. Then, wrap the action in a custom command that retries the operation using Cypress’s built‑in retry‑ability: cy.get().click().should(() => { expect(response).to.have.property('status', 200); }); This demonstrates control over network behavior and uses Cypress’s automatic retries to handle transient errors. Interviewers appreciate a solution that avoids manual loops and stays within Cypress’s command queue.