World’s largest virtual agentic engineering & quality conference
Top 65 Cypress interview questions and answers for freshers and experienced QA engineers, covering architecture, cy.intercept, hooks, and cypress.config.js.

Devansh Bhardwaj
Author

Navin Chandra
Reviewer
Published on: November 25, 2025
Last Updated on: August 17, 2026
On This Page
Cypress is a popular end-to-end testing framework for web applications. It allows developers to write and run tests in a browser, providing a fast, efficient, and reliable way to ensure that web applications function correctly and meet the user's requirements.
Cypress is an excellent tool for testing complex applications because it provides a simple and powerful API for interacting with your application and built-in support for network and XHR requests. With an intuitive user interface that makes it easy to write and debug tests, Cypress makes writing comprehensive tests easier than ever before.
These 65 questions run from fundamentals to advanced techniques, and every answer has been checked against the current Cypress documentation. That matters more than usual on this topic, because Cypress 10 renamed the configuration file, the specs folder, and the network stubbing command, and many Cypress answers still circulating online describe the release line those changes replaced.
Where an outdated answer is still in wide circulation, the questions below name it explicitly, so you can recognize the trap rather than repeat it in front of an interviewer.
To back up that preparation with a credential, you can also earn a free Cypress certification and validate your fundamentals before the interview.
TL;DR
Download Cypress Interview Questions
Note: We have compiled all Cypress Interview Question for you in a template format. Feel free to comment on it. Check it out now!!
Cypress is an open-source JavaScript testing framework that makes it easier and more efficient for developers to write and run automated tests for their web applications. It provides a comprehensive set of tools and features that enable developers to create, run, and debug tests quickly and easily.
Cypress addresses several challenges developers face when testing modern web applications, and offers these advantages over WebDriver-based frameworks:
In Cypress, we have several options for handling reusability. One approach is to use custom commands, allowing us to create reusable functions and actions that can be called from anywhere to tackle any question that comes your way during your in our tests. Using the Cypress Page Object Model design pattern, we can also use fixtures to store reusable test data or create reusable page objects.
Ordering is controlled by the specPattern option in cypress.config.js. The Cypress configuration reference defines specPattern as a glob or array of globs of the test files to load, and Cypress loads an explicit array in the order you write it.
Older answers put this in a testFiles property inside cypress.json. Neither is recognized by current Cypress releases, so an answer built on testFiles places the candidate on Cypress 9 or earlier.
// cypress.config.js
const { defineConfig } = require('cypress')
module.exports = defineConfig({
e2e: {
specPattern: [
'cypress/e2e/login.cy.js',
'cypress/e2e/checkout.cy.js'
]
}
})
Worth adding out loud: ordering specs this way creates dependencies between tests, so most teams keep specs independent and reach for ordering only when a flow genuinely requires it.
Cypress uses the following assertions:
Also, we can write our own assertions using Chai assertions.
The Cypress Fixture command lets you load a fixed set of data in a file to maintain test data in Cypress. The fixture directory stores various "JSON" files, and these JSON files can store the test data, which multiple tests can read. You can store test data in the form of key values, enabling you to access it during scripting.
Also Read: A list of 70 Cucumber Interview Questions and Answers
Hooks in Cypress let you run code at specific points in your test suite or test case. They provide a way to set up and tear down test fixtures, perform actions before or after each test, and modify test behavior dynamically.
There are several types of hooks available in Cypress:
Hooks provide a way to ensure that your tests are properly set up and cleaned up and that any dependencies or fixtures are properly managed. This can help reduce test flakiness and make your tests more reliable.
Yes, Cypress can be used with Behavior-Driven Development (BDD) to write tests in a more human-readable format that also aligns with your business goals. Cypress, a testing framework for web applications, has adopted Mocha's BDD syntax, which fits perfectly with integration and unit testing. Also, it can be integrated with Cucumber using Plugin.
If you want to interact with DOM elements, you can use CSS selectors. Also, many built-in commands can be used to interact with elements. If you want to use XPath, you must install an external plugin.
Yes, Cypress uses Mocha as its default testing framework. Cypress extends Mocha with additional features specific to browser testing, such as the ability to interact with the DOM, make network requests, and capture screenshots and videos of test runs.
Use cy.intercept() to spy on and stub network requests and responses.
Older material answers this with cy.route(), which current Cypress releases no longer provide. Naming cy.intercept() is the answer interviewers expect.
// Spy only: let the real call through, then assert on it
cy.intercept('GET', '/api/users').as('getUsers')
cy.wait('@getUsers').its('response.statusCode').should('eq', 200)
// Stub: return fixture data without hitting the network
cy.intercept('GET', '/api/users', { fixture: 'users.json' }).as('stubUsers')
The distinction interviewers listen for is that cy.intercept() spies by default and only stubs when you supply a response, so one command covers both cases.
Cypress is a JavaScript testing framework that uses Node.js and is available as an npm module. It uses JavaScript because it is based on Node.js.
Per the Cypress launching browsers documentation, Cypress supports Chrome-family browsers (Chrome, Chromium, Chromium-based Edge, and the bundled Electron), Firefox, and WebKit, which is Safari's engine and is still experimental. Cypress officially supports the latest three major versions of Chrome, Firefox, and Edge.
Opera and Internet Explorer are not supported. Candidates often name Opera here because older tutorials list it, so it is worth stating the supported set precisely.
Cypress has three main components:
Cypress runs in the background of the browser, while Node.js runs in the background of Cypress. The two programs regularly interact and perform actions that support each other.
Cypress has access to the front and back end of the application, allowing it to alter the browser behavior at run time. It can handle DOM and modify requests and responses of the network on the fly.
Cypress is a free and open-source test runner for writing, running, and debugging tests locally while you build the application. Around the runner sits a plugin ecosystem, official CI integrations, and Cypress Cloud, the paid recording service that stores run history and test analytics. Cypress Cloud was renamed from Cypress Dashboard in 2023, so use the current name.
Some key features of Cypress include:
Cypress supports multiple operating systems, including:
Cypress also requires Node.js 20.x, 22.x, or 24.x and newer, as listed in the Cypress installation requirements.
Older answers to this question name Windows 7 and macOS 10.9. Both fall below the minimums above, so quoting them in an interview signals stale knowledge.
Shadow DOM allows you to create an inner structure for an element that is not visible from the outside but can be accessed from within the element. Shadow DOM has been used for some time by browsers to encapsulate the inner structure of an element. The shadow() function handles shadow DOM:
cy.get('#locator').shadow().find('.nb-btn').click()
The .first() and .last() commands in Cypress can be used to select a selected element's first and last child elements. This is demonstrated in the following example:
// Get the first child of a selected element
cy.get('ul li').first()
// Get the last child of a selected element
cy.get('ul li').last()
The above example uses the get() method to select all the li elements that are children of the ul element and then uses first() and last() commands to select the first and last child elements, respectively.
The `cy.wait()` command can be used to pause a test for a specified amount of time. This command can be used to simulate a delay, such as waiting for an element to load or for a request to complete.
Configuration values live in cypress.config.js at the project root, and you read them in a test with the Cypress.config() method. Cypress also accepts cypress.config.ts, cypress.config.mjs, and cypress.config.cjs, so a TypeScript project keeps its config typed.
You can simulate keyboard input in Cypress by typing `cy.type()` command into an element or pressing specific keys on the keyboard. To simulate pressing a specific key on the keyboard, use the `` syntax with the `cy.type()` command to pass the corresponding key code.
Cypress allows you to create custom commands using the `Cypress.Commands.add()` method, which encapsulates repetitive or complex functionality into reusable commands, making your tests more readable and maintainable.
By default, Cypress clears all cookies before each test to ensure a clean slate. However, there are times when you want to preserve cookies between tests or even across different test runs. You can use the `cy.getCookies()` and `cy.setCookie()` commands to do this.
Changing the `baseUrl` dynamically in your test code using `Cypress.config()` method allows you to set the `baseUrl` to a different value depending on the test scenario, making your tests more flexible and reusable.
You can override the same using the command line:
npx cypress run --config baseUrl="https://www.testmuai.com/selenium-playground/"
When writing Cypress tests, environment variables can be used to store sensitive data such as API keys or credentials and to configure your tests based on the environment in which they are running.
You can set them in the env block of cypress.config.js, in a cypress.env.json file, through CYPRESS_ prefixed shell variables, or with the --env command line flag. Read them back in a test with Cypress.env(). Interviewers often follow up on precedence: command line values override config file values.
Cypress, unlike other testing frameworks, does not natively support XPath selectors. But you can use the `cy.xpath()` command provided by the `cypress-xpath` plugin to select elements using XPath expressions.
You can also use this free XPath Tester tool that is designed to allow users to test and evaluate XPath expressions or queries against an XML document. It helps ensure that the XPath queries are accurate and return the expected results.
Cypress supports several types of selectors that can be used to locate and interact with elements on a web page. Here are some examples of selectors Cypress supports:
Cypress does not support working in a new window. You need to open a new window in the same tab only. To do this, remove the attribute target from the link element.
Say the page under test contains this markup:
<a href="https://www.testmuai.com/selenium-playground/" target="_blank">Selenium Playground</a>
That link opens the Selenium Playground in a new tab because of the target attribute, which puts it outside the reach of Cypress commands. Strip the attribute first, then click:
cy.get('a[href*="selenium-playground"]')
.invoke('removeAttr', 'target')
.click()
cy.contains('Selenium Playground').should('be.visible')
With the attribute removed, the page loads in the same tab and Cypress can assert against it normally. Interviewers ask this to check that you understand why Cypress restricts multi-tab flows rather than just memorizing a workaround.
Here are five Cypress commands that can be used to interact with DOM elements:
These commands can be combined with the various selectors supported by Cypress to target specific DOM elements and interact with them in different ways.
To simulate a click on a button in Cypress, use the cy.get() command to select the button element and then use the cy.click() command. Here's an example:
// Find the button by its ID attribute cy.get('#my-button').click()
// Find the button by its class name cy.get('.my-button-class').click()
// Find the button by its text content cy.contains('Click Me').click()
You can create test suites in Cypress by grouping related tests into separate files and folders. Each file or folder can be considered a separate test suite.
Open cypress.config.js at the project root to see what your project overrides. Cypress scaffolds this file the first time you run npx cypress open and pick a testing type.
To see the full resolved configuration, including every default your project has not overridden, open the Settings tab in the Cypress app. It shows each value alongside where it came from, which is the detail that separates a candidate who has opened the panel from one who has only read about it.
You can follow these steps to setup and run your first Cypress test script:
To run a single spec file in Cypress using the command line, you can use `cypress run --spec` followed by the path to your spec file. An example command would be:
npx cypress run --spec cypress/e2e/my-spec.cy.js
Here we run the Cypress run command with the --spec flag pointing at cypress/e2e/my-spec.cy.js. Since Cypress 10 the specs folder is cypress/e2e rather than cypress/integration. One catch worth mentioning: --spec only runs files that also match the configured specPattern, so a path outside that pattern silently matches nothing.
The Cypress CLI (Command Line Interface) is a set of commands that allows you to interact with Cypress from the command line, run tests, open the Cypress Test Runner and manage your Cypress installation.
We can install the Cypress CLI by using NPM by running the following command in your terminal:
npm install cypress -g
Cypress scaffolds a recommended structure on first run. The layout changed in Cypress 10, so answer with the current one:
Naming the cypress/plugins folder as if it still exists is one of the quickest ways to signal that your Cypress experience stopped before version 10.
We can follow the below steps to open the Cypress Test Runner and execute tests.
Cypress is a JavaScript testing framework based on Mocha, but it adds some unique functionality. For example, Cypress can interact with the browser and the DOM to provide a more robust and intuitive experience than other test runners.
Here are some of the advantages of using Cypress:
Here are some of the disadvantages of using Cypress:
Here is the difference between Cypress and Selenium:
No. Cypress specs are written in JavaScript or TypeScript only, and there are no official C#, Java, or PHP bindings. This is a genuine difference from Selenium, which offers official clients in several languages.
The application under test can be written in any language, since Cypress drives it through the browser. If your team's automation skills sit in Java or C#, that constraint usually decides the framework choice, and saying so directly is a stronger answer than claiming Cypress supports every language.
Here are some key differences between the architectures of Cypress and Selenium:
As the application is under test, Cypress runs in the same run loop allowing it to execute code alongside it. This architecture makes Cypress faster and more efficient than Selenium, which uses a client-server architecture that requires communication between the test script and the browser via a WebDriver server.
Cypress controls the browser directly, while Selenium uses WebDriver to send commands to the browser. This means that Cypress can bypass limitations imposed by WebDriver and provide more significant support for certain browser APIs than possible using only WebDriver.
Cypress provides an interactive test runner that lets developers see what's happening in their tests in real time. This makes debugging easier and more efficient. Selenium, on the other hand, relies on third-party tools for debugging.
Selenium and Cypress are two different frameworks that support software testing differently. Selenium supports a wide range of programming languages, while Cypress is primarily a JavaScript framework. Although Cypress can be used with other languages, it is most effective with JavaScript.
The `cypress.contains()` command is one of the many useful features of Cypress, an open-source end-to-end testing framework for web applications. This command can be used to search for specific text content on a webpage and interact with it by using their contents. Here is an example of the same:
// Returns the first element containing the text "Hello"
cy.contains('Hello')
// Scopes the search to elements with the .button class
cy.get('.button').contains('Click me')
The Cypress library provides a way to navigate back and forward in browser history. The cy.go() function can be used for this purpose:
cy.go('back') or cy.go(-1) is used to navigate to previous browser history and cy.go('forward') or cy.go(1) is used to go forward in browser history.
You can use the Cypress commands cy.wait() and cy.get() to wait for an element to be visible. Here's an example:
cy.get('#my-element').should('be.visible');In the above example, the Cypress should() command is used to make an assertion that an element is visible. If the element is not visible, Cypress will automatically retry the assertion until the element becomes visible or the test times out.
When an element is hidden on a page, you cannot click it directly with the cy.click() command in Cypress. However, you can use the cy.get() command with the [force: true ] option to force Cypress to click on the element, even if it is hidden. Here's an example of the same:
cy.get('#my-hidden-element').click({ force: true });Read Cypress.browser for details about the browser running the spec, and cy.window() when you need the application's window object. Cypress.browser exposes name, family, version, and the isHeadless flag, which makes it useful for skipping tests that a given browser cannot run.
// Browser metadata Cypress already knows about
cy.log(Cypress.browser.name, Cypress.browser.version)
// Skip a spec on a browser that cannot support it
if (Cypress.browser.family !== 'chromium') {
cy.log('Skipping: Chromium-only test')
}
// Reach the application window when you need navigator
cy.window().then((win) => {
cy.log(win.navigator.userAgent)
})
Some older guides answer this with cy.state(), which is an internal API that Cypress does not document for test code and can change without notice. Naming Cypress.browser and cy.window() instead is the safer answer.
Here are some Cypress functions that are useful for traversing the DOM:
The trigger() function in Cypress programmatically simulates user interactions with the page, such as a click, mouseover, or key-down event. This can be useful in testing scenarios where you need to test the behavior of components under different circumstances.
Here's an example of how you can use the trigger() function to simulate a click event on a button element:
cy.get('button').trigger('click');
In Cypress, you can simulate a mouseover event on an element by using the .trigger() method. This method accepts a string argument representing the name of the event you want to trigger, such as 'mouseover'.
To use mouseover in Cypress, select the element you want to trigger the event using the cy.get() command. Then chain the .trigger() method to simulate the event.
To perform drag and drop operations in Cypress, you can use the cy.get() command to select the element you want to drag, then trigger a mousedown event on that element to start the drag operation. After that, simulate a mousemove event on the element to move it to its new position, then trigger a mouseup event to drop it at its new position. Here's an example:
cy.get('.draggable')
.trigger('mousedown', { button: 0 })
.trigger('mousemove', { clientX: 100, clientY: 100 })
.trigger('mouseup')
Cypress offers a cy.location() command that returns a location object for the current window. The location object contains information about the current URL, such as protocol, host, pathname and search parameters. Here's an example of how to use cy.location():
cy.location().then((loc) => { console.log(loc.pathname)})
In this example, the cy.location() command retrieves the location object for the current window, and then the .then() method is used to access the location object's pathname property and log it to the console.
In Cypress, you can use the cy.get() command to select DOM elements, and several filtering methods are available with which to narrow down your selection based on specific criteria. These include .filter(), .eq(), .first(), .last(), and .contains().
The after:run event fires in the Node process once a whole cypress run finishes, and it receives the run results. You register it inside setupNodeEvents in cypress.config.js, not in a spec file, which is the distinction interviewers look for. Related Node events include before:run, before:spec, and after:spec.
// cypress.config.js
const { defineConfig } = require('cypress')
module.exports = defineConfig({
e2e: {
setupNodeEvents(on) {
on('after:run', (results) => {
console.log('Total failed:', results.totalFailed)
})
}
}
})
The cy.task() function is a powerful Cypress API that allows you to execute tasks in the Node.js environment outside of the browser context. This function can be used to perform a variety of complex operations that cannot be done within the browser, such as interacting with APIs or databases, executing command-line tools, or reading and writing files.
Practice These Answers on Real Browsers
Note: Cypress runs only on Chrome-family browsers, Firefox, and experimental WebKit, so "how do you cover Safari and older browsers?" is a standard follow-up. TestMu AI's test automation cloud runs your existing Cypress specs across 3,000+ real browser and OS combinations in parallel, capturing network logs, console logs, video, and a command-by-command replay on every session. Try it free!
Cypress's cy.exec() function allows you to execute a command-line command or shell script outside of the browser context. This function can be used to perform tasks that cannot be done within the browser, such as running build scripts, interacting with command-line tools, or executing system commands.
In Cypress, you can read files using the cy.readFile() and cy.fixture() functions. The cy.readFile() function reads the contents of a file from the project's file system, while the cy.fixture() function loads a fixture file, a pre-defined set of data that can be used in your tests. This can be useful if you want to work with the same source code or data set repeatedly throughout your tests without manually entering it.
In Cypress, you can use the cy.writeFile() function to save data in your project's file system. This function takes two arguments: a string representing the path to the file you want to write, and a string containing the data you want to write to that file.
Here's a simple example of how you can use cy.writeFile() to write some text to a file:
const fileContents = 'This is some text that will be written to a file.'cy.writeFile('path/to/file', fileContents)
Cypress ships with Mocha's reporters and adds teamcity and junit. Set one with the reporter option in cypress.config.js or the --reporter flag on the command line. The default is the spec reporter, which prints results to the terminal in a readable outline. Teams usually switch to junit so CI systems can parse the output.
Debugging your tests can be an important part of the testing process. Cypress provides several ways to do so, including the cy.pause() command, which pauses execution at a specific point and allows you to use the browser's DevTools to debug your code.
Another handy way to debug your tests is to use the cy.debug() command. This command logs the current state of your application's DOM and Cypress commands in the Command Log, allowing you to view what's happening with your app at any given point during a test run.
The cy.clearCookies() and cy.clearLocalStorage() commands in Cypress allow you to clear the cookies and local storage data of the currently focused browser window. The cy.clearCookies() command can be used to clear all cookies for a given domain, while the cy.clearLocalStorage() command can clear all data stored in local storage for a given domain.
Clearing cookies and local storage is useful when testing the behavior of a website. Clearing cookies can be used to test whether the site behaves correctly when users log out. Similarly, clearing local storage can be used to test whether the site behaves correctly when specific data is missing or deleted from the local repository.
Timeouts can occur in Cypress tests for a variety of reasons, such as slow network requests or heavy computations. Cypress provides several configuration options that can be used to handle these situations.
Performing Cypress API testing is straightforward, and you can use the built-in cy.request() command to do so. The following example shows how to perform an API test in Cypress:
// cy.request({
method: 'POST',
url: '/api/boards',
body: {
name: 'space travel plan'
}
})
Reading answers is not the same as having written the code. TestMu AI publishes agent skills for Cypress, which are self-contained packages of instructions, code patterns, debugging guides, and CI/CD configurations for a specific framework. The cypress-skill teaches an AI coding assistant to work like an experienced QA architect: correct project structure, dependency management, local and cloud execution, debugging strategy, and pipeline setup.
Install it by copying the skill into your assistant's skills directory. The path varies by tool, using .cursor/skills/ for Cursor and .github/skills/ for GitHub Copilot:
git clone https://github.com/LambdaTest/agent-skills.git
cp -r agent-skills/cypress-skill .claude/skills/
export LT_USERNAME="your_username"
export LT_ACCESS_KEY="your_access_key"
Then ask for what you want in plain language, for example "write Cypress E2E tests for the login page and run them on TestMu AI cloud using Chrome and Firefox". The skill handles project setup, execution config, and routing to the cloud grid. It works with Claude Code, GitHub Copilot, Cursor, Gemini CLI, Codex CLI, and OpenCode.
For interview prep the value is the turnaround: you can generate a spec for a question above, run it, read the failure, and fix it in the time it would take to reread the answer. Walking an interviewer through a bug you diagnosed carries far more weight than reciting a definition.
Start by writing one spec that uses cy.intercept() to stub an API response and asserts on the rendered result. That single test exercises the three things interviewers probe hardest: the in-browser architecture, network control, and assertion style. Being able to talk through code you actually wrote beats reciting definitions.
Then run it somewhere other than your laptop. The getting started with Cypress testing documentation walks through pointing an existing spec at the TestMu AI grid, which gives you a real build URL and session artifacts to reference when an interviewer asks what you have actually shipped.
Author
Devansh Bhardwaj is a Community Evangelist at TestMu AI with 4+ years of experience in the tech industry. He has authored 30+ technical blogs on web development and automation testing and holds certifications in Automation Testing, KaneAI, Selenium, Appium, Playwright, and Cypress. Devansh has contributed to end-to-end testing of a major banking application, spanning UI, API, mobile, visual, and cross-browser testing, demonstrating hands-on expertise across modern testing workflows.
Reviewer
Navin Chandra is a Member of Technical Staff at TestMu AI (formerly LambdaTest), building the open-source automation that powers its Selenium and Appium cloud grid. A committer to both Selenium and Appium, he implemented WebDriver BiDi support in Selenium for real-time browser events and bidirectional control and is developing Apple's iOS RemoteXPC protocol in Appium to enable low-level wireless communication with iOS system services. He contributes to Selenium across multiple language bindings as a member of the Selenium GitHub organization. He has served as a Google Summer of Code mentee and mentor at openSUSE and an LFX mentee at CNCF's KubeArmor, and is a SUSE Certified Deployment Specialist. Navin holds a B.Tech in Computer Science.
Did you find this page helpful?
More Related Blogs
TestMu AI forEnterprise
Get access to solutions built on Enterprise
grade security, privacy, & compliance