Top 25 Cypress
Interview Questions

Cypress is a next-generation front-end testing tool built for the modern web. Unlike Selenium, which operates outside the browser and communicates through the WebDriver protocol, Cypress runs directly inside the browser alongside the application code.

Cypress executes its tests within the same run-loop as your application. It runs a Node.js server in the background, while the tests execute inside the browser. The Node server and browser communicate using WebSockets.

Cypress commands (like cy.get, cy.click) are the building blocks of tests. They don't execute immediately; instead, they are enqueued to be run sequentially later. Behind the scenes, Cypress commands are essentially asynchronous promises.

Cypress has built-in 'Auto-Waiting'. It automatically waits for elements to exist in the DOM, become visible, become actionable (not disabled, not covered), and finish animating before it executes a command like clicking or typing.

Fixtures are external files (usually JSON) that store static mock data. They are used to stub network responses, provide test data for form inputs, or mock application state, keeping your test files clean and data-driven.

The Cypress configuration file (cypress.config.js or ts in v10+, previously cypress.json) stores global project settings. It defines parameters like baseUrl, default command timeouts, viewport dimensions, environment variables, and folder structures.

You use the `should` assertion with the Chail-jQuery matcher `be.disabled`.

Cypress handles API calls using `cy.request()` to make direct HTTP requests, and `cy.intercept()` to spy on or stub network traffic initiated by the browser application.

`cy.intercept()` is used to spy on, stub, or modify network requests and responses made by the browser. It allows you to simulate backend behavior without needing a real server.

`cy.get()` selects elements based on CSS selectors (like ID, class, or data attributes). `cy.contains()` selects elements based on the text content visible inside them.

Custom commands allow you to extend the Cypress `cy` object with your own reusable functions. They are used to abstract repetitive logic, like logging into an application or setting up specific state.

Handling iframes in Cypress requires a workaround because Cypress cannot inherently cross the iframe boundary due to browser security restrictions. You have to manually target the iframe's content window.

These Mocha hooks manage test setup and teardown operations. `before()` runs once before all tests in a block, `beforeEach()` runs before every single test, `after()` runs once after all tests, and `afterEach()` runs after every single test.

Historically, Cypress required a third-party plugin for file uploads. However, since version 9.3.0, Cypress natively supports file uploads using the `selectFile()` command.

Plugins extend Cypress's native functionality by allowing you to tap into the Node.js process running behind the browser. This allows Cypress to do things the browser can't, like read files, query databases, or process configuration.

You integrate Cypress into CI/CD by running Cypress via its CLI command `npx cypress run` in the CI pipeline script. The pipeline must have an environment that supports browsers (usually a Docker container provided by Cypress, like `cypress/included`).

You run Cypress in headless mode using the command `npx cypress run`. By default, this executes the tests headlessly (without a visible UI) using the Electron browser.

Yes, Cypress supports testing across multiple browsers. It currently supports Chromium-based browsers (Chrome, Edge, Electron) and Firefox.

`.should()` is an assertion command that automatically retries until the assertion passes or times out. `.then()` is a utility command used to access the yielded subject (like an element or a string) to write custom code or handle asynchronous data.

Test retries tell Cypress to re-run a failing test case a specified number of times before ultimately marking it as a failure. This helps mitigate test flakiness caused by network blips or unpredictable DOM rendering.

When running tests in headless mode (`cypress run`), Cypress automatically captures a screenshot whenever a test fails and records a video of the entire test run by default.

Cypress has several distinct architectural limitations: it cannot easily interact with multiple browser tabs or windows, it cannot handle native mobile app testing, and it historically struggles with cross-origin domains within the same test.

`cy.visit()` loads an HTML page into the Cypress browser UI and waits for the page to fire its load event. `cy.request()` makes an HTTP request under the hood, completely bypassing the browser UI.

A standard Cypress project is structured logically: `cypress/e2e/` holds the actual test spec files. `cypress/fixtures/` contains mock JSON data. `cypress/support/` holds global configurations, custom commands (`commands.js`), and index file.

A common challenge is dealing with elements that detach from the DOM (the 'detached from DOM' error) when a modern React/Vue application aggressively re-renders the UI during a test.