Cypress interview questions and answers

Cypress runs inside the browser alongside your app, controlled by a Node process, so it can read the DOM, stub network calls and control time directly. Commands are queued and run with automatic retries, and the runner shows each step with DOM snapshots (time travel). Selenium drives browsers from outside through WebDriver. Cypress is JavaScript-only and limited to one tab and one origin per test, though cy.origin handles cross-origin steps.

Queries such as cy.get and their assertions retry until the assertion passes or the timeout (4 s by default) expires, so tests wait naturally for the app. Actions such as .click() do not retry. Chain assertions directly after queries and avoid splitting them with non-retrying commands.

Commands are enqueued and run later in order, so const el = cy.get('x') does not give you the element. Use .then(el => ...) to work with yielded values, aliases (.as('user') and cy.get('@user')), or assertions. Mixing async/await with Cypress commands does not work.

cy.intercept(method, url, response) stubs responses with fixtures or modifies requests; without a response it only spies. Give it an alias with .as('getUsers') and cy.wait('@getUsers') to wait for that call and assert on its request and response, instead of fixed waits.

Organise specs by feature, put shared actions in custom commands or small helper modules (App Actions rather than heavy page objects), seed data through API or cy.task, use data-cy selectors, keep tests independent and short, and run them in parallel in CI.

Fixed waits (cy.wait(5000)), asserting before network data arrives, detached DOM elements after re-renders, shared state between tests, and animations. Fix with assertions that retry, waiting on aliased requests, re-querying instead of storing elements, test isolation and disabling animations.

Commands are enqueued when the test function runs and executed later, in order, by Cypress. That is why you cannot assign their results to variables; you chain with .then() or .should(), and Cypress waits and retries for you.

Use stable attributes dedicated to tests, such as data-cy or data-testid, or accessible text with cy.contains. Avoid brittle CSS classes, tag names and positional selectors that change with styling.

Log in programmatically through the API (cy.request) rather than through the UI in every test, and cache the session with cy.session(id, setup), which saves cookies and storage and restores them in later tests. Test the login UI itself in one dedicated spec.

Reusable commands added with Cypress.Commands.add('login', (email) => { ... }) in the support file, so tests can call cy.login(email). Type them in a .d.ts for TypeScript. Keep them small and well-named.

Reset state before each test (seed the database through an API or cy.task), never depend on another test's results, stub third-party services, and use fixtures. Clean up in beforeEach, not afterEach, so a failed test cannot leave bad state behind.

Running commands on a different origin within one test, for example a third-party login page. Code inside cy.origin(url, () => {...}) runs in that origin's context; you pass values in through the args option.

Use cy.get('input[type=file]').selectFile('cypress/fixtures/file.pdf') (also supports drag-and-drop). For downloads, check the downloads folder with cy.readFile after the click.

Use cy.request to log in and receive a token or cookie, set it with cy.setCookie or localStorage, and wrap it in cy.session so it is cached and restored for every test, testing the UI login only once.

By default, Cypress clears the page, cookies, localStorage and sessionStorage before each test, so tests do not depend on each other. Use cy.session to restore login state explicitly.

Use cy.request to call endpoints and assert on status, headers and body. Plugins add nicer logging. It is handy for setup and smoke checks, though dedicated API test tools may suit large API suites.

Cypress Cloud balances specs across machines with --record --parallel. Without it, split specs manually or with third-party tools, and run in the official Docker images with dependencies installed.

Mounting individual React, Vue, Angular or Svelte components in a real browser with cy.mount, using your dev server's bundler, and testing them with the same Cypress commands. It sits between unit tests and full end-to-end tests.

It runs code in the Node process (defined in setupNodeEvents), for things the browser cannot do: seeding a database, reading files, or calling services. It returns a value back to the test.

cy.clock() freezes Date, setTimeout and setInterval, and cy.tick(ms) moves time forward, so you can test countdowns or session timeouts without waiting.

Run cypress run headless, start the app first (for example with start-server-and-test), record or upload screenshots and videos as artifacts, and parallelise specs across machines with Cypress Cloud or your own splitting.

Use cypress-axe: cy.injectAxe() after visiting and cy.checkA11y() to report violations, plus keyboard checks such as focus order with cy.focused().

should retries its assertions until they pass or time out. then runs once with the yielded value and does not retry, so use it only when you need the value for further logic.

Use the Test Runner's time-travel snapshots, cy.pause() and .debug(), inspect yielded values in DevTools console, review screenshots and videos from CI, and add cy.log messages.

Call cy.viewport('iphone-x') or cy.viewport(375, 812) in tests or config, and assert that mobile menus and layouts behave correctly.

Set them in cypress.config env, in cypress.env.json, or as CYPRESS_* OS variables, and read them with Cypress.env('name'). Keep secrets out of the repository.

Cypress has limited native iframe support: get the iframe, wait for its body to load, then wrap it with cy.wrap(body) and query inside, or use a plugin such as cypress-iframe.

JSON or other files in cypress/fixtures loaded with cy.fixture('users.json') or referenced in cy.intercept(..., { fixture: 'users.json' }), giving consistent test data.

Cypress controls one tab. Remove the target="_blank" attribute and click, or assert on the link's href and visit it directly.

Configure the component testing framework (React with Vite or webpack), mount components with cy.mount(<Button />), interact as in end-to-end tests, and stub props or network calls.

1. Acy.fetch
2. Bcy.request
3. Ccy.interceptCorrect answer
4. Dcy.route only

Why: cy.intercept replaced the older cy.route.

1. A30 seconds
2. BNo timeout
3. C1 second
4. D4 secondsCorrect answer

Why: defaultCommandTimeout is 4000 ms.

1. A.then(el => ...)Correct answer
2. Bawait cy.get(...)
3. Ccy.get(...).value
4. Dconst el = cy.get(...)

Why: Commands are queued, not promises.

1. AIt is a lint rule only
2. BCommands are enqueued and run laterCorrect answer
3. CThey return null
4. DThey are synchronous

Why: Use .then() or aliases.

1. AMore retries in CI only
2. BDisabling tests
3. CRetrying assertions and waiting on aliased requestsCorrect answer
4. Dcy.wait(5000)

Why: Avoid fixed sleeps.

1. ANothing
2. BOnly cookies
3. COnly the database
4. DPage, cookies and storageCorrect answer

Why: Test isolation.

1. Acy.cookie
2. Bcy.store
3. Ccy.login
4. Dcy.sessionCorrect answer

Why: cy.session saves and restores session state.

1. A'.btn-primary'
2. B'[data-cy=submit]'Correct answer
3. C'div > button:nth-child(2)'
4. D'button'

Why: Dedicated test attributes do not change with styling.

1. Acy.wait('@getUsers')Correct answer
2. Bcy.pause()
3. Ccy.until('@getUsers')
4. Dcy.wait(3000)

Why: Wait for the specific call, not a duration.

1. A.click()Correct answer
2. B.should()
3. Ccy.get
4. Dcy.find

Why: Actions run once; queries retry.

1. Acy.visit only
2. Bcy.domain
3. Ccy.switch
4. Dcy.originCorrect answer

Why: Pass values with args.

1. AattachFile (built-in)
2. Bupload
3. Ccy.file
4. DselectFileCorrect answer

Why: Built in since Cypress 9.3.

1. ABoth
2. BNeither
3. CshouldCorrect answer
4. Dthen

Why: then runs once.

1. Acypress-a11y-core
2. Blighthouse-cypress
3. Caxe-cli
4. Dcypress-axeCorrect answer

Why: cy.checkA11y.

1. Acy.window
2. Bcy.viewportCorrect answer
3. Ccy.resize
4. Dcy.screen

Why: Presets like iphone-x.

1. Acy.node
2. Bcy.server
3. Ccy.exec only
4. Dcy.taskCorrect answer

Why: Tasks are defined in setupNodeEvents.

1. Acy.render
2. Bcy.visit
3. Ccy.component
4. Dcy.mountCorrect answer

Why: Used in component testing mode.

1. Acy.now
2. Bcy.clock and cy.tickCorrect answer
3. Ccy.time and cy.wait
4. Dcy.date and cy.sleep

Why: clock freezes timers; tick advances them.

1. Anode_modules
2. Bcypress/videos
3. Ccypress/supportCorrect answer
4. Dcypress/fixtures

Why: The support file loads before every spec.

1. Acy.env()
2. BCypress.config('env')
3. CCypress.env('name')Correct answer
4. Dprocess.env.name

Why: From config or CYPRESS_ vars.

1. Acy.stop()
2. Bcy.break()
3. Cdebugger only
4. Dcy.pause()Correct answer

Why: Step through commands.

1. Acy.http
2. Bcy.intercept
3. Ccy.requestCorrect answer
4. Dcy.fetch

Why: intercept stubs; request calls.

1. A--threads
2. B--record --parallelCorrect answer
3. C--split
4. D--shard

Why: Requires a record key.

1. Acy.render
2. Bcy.component
3. Ccy.create
4. Dcy.mountCorrect answer

Why: Framework-specific mount.

1. Acypress/downloadsCorrect answer
2. Bcypress/fixtures
3. Ctmp/
4. DThe user's Downloads

Why: Read them with cy.readFile.

1. Acypress open
2. Bcypress runCorrect answer
3. Ccypress start
4. Dcypress ci

Why: open launches the interactive runner.

1. Acy.readFile only
2. Bcy.data
3. Ccy.load
4. Dcy.fixtureCorrect answer

Why: Fixtures live in cypress/fixtures.

1. Acy.originCorrect answer
2. Bcy.domain
3. Ccy.cross
4. Dcy.switch

Why: cy.origin runs commands against a different origin.

1. Aenv.cy.js
2. Bcypress.env.jsonCorrect answer
3. C.cypressrc
4. Dcypress.secrets

Why: Keep it out of Git.

1. ANot possible at all
2. BOnly in Firefox
3. CLimited; wrap the iframe bodyCorrect answer
4. DFull

Why: Plugins help.