Cypress Interview Questions (2026)
Cypress interview questions test your understanding of browser testing, command chains, automatic retries, selectors, fixtures, intercepts, component tests, CI runs, and flaky test fixes.
45 questions with answersWhat Is Cypress?
Key Takeaways
- ✓Cypress is a JavaScript testing tool for web apps, with support for end-to-end and component testing.
- ✓Interviews focus on command chains, automatic retry, selectors, fixtures, intercepts, assertions, and CI behavior.
- ✓Cypress runs in a browser and gives strong debugging feedback through time travel, screenshots, videos, and network controls.
- ✓Strong candidates know Cypress strengths and limits instead of saying it replaces every automation tool.
Cypress is a JavaScript-based testing tool for modern web applications. It is commonly used for browser workflow tests, component tests, API-backed UI checks, and local debugging. In interviews, Cypress questions test whether you understand its command queue, retry model, selectors, assertions, network stubbing, fixtures, and CI reporting.
Watch: Cypress Complete Beginners Masterclass
Video: Cypress Complete Beginners Masterclass (Automation Step by Step, YouTube)
Test yourself and earn a certificate
6 quick questions. Score 70%+ to download your Cypress certificate.
All Questions on This Page
45 questions- 1. What is Cypress used for?
- 2. What is the Cypress command queue?
- 3. What does Cypress retry automatically?
- 4. What does cy.get do?
- 5. Why use should in Cypress?
- 6. What are Cypress fixtures?
- 7. What is cy.intercept used for?
- 8. What are custom commands?
- 9. Why use cy.session?
- 10. What is Cypress component testing?
- 11. What is test isolation in Cypress?
- 12. Why are Cypress screenshots and videos useful?
- 13. How does Cypress actionability affect clicks?
- 14. When should you stub network calls?
- 15. What Cypress limitations should you mention?
- 16. How would you write a Cypress login test?
- 17. How do you choose Cypress selectors?
- 18. How do you wait for an API call?
- 19. How do you test an empty state with Cypress?
- 20. How do you test an API error state?
- 21. How do you use fixtures well?
- 22. When would you create a custom command?
- 23. How do you debug a Cypress failure?
- 24. How do you run Cypress in CI?
- 25. How do you split Cypress suites?
- 26. How do you avoid logging in through UI for every Cypress test?
- 27. How would you test a component in Cypress?
- 28. How do you avoid cy.wait with fixed time?
- 29. How can Cypress support accessibility checks?
- 30. How do you keep Cypress tests maintainable?
- 31. A Cypress test uses cy.wait(5000) and still fails. What do you change?
- 32. A UI class rename broke many tests. What is the lesson?
- 33. A test passes with stubbed responses but production fails. What happened?
- 34. Every spec logs in through UI and the suite is slow. What do you do?
- 35. A Cypress test passes only after another test runs first. What is wrong?
- 36. A fixture no longer matches the API contract. How do you prevent this?
- 37. A payment or auth flow crosses domains. What do you consider?
- 38. Cypress says a button is covered. What do you inspect?
- 39. A Cypress test passes locally but fails in CI. What do you check?
- 40. A framework hides every action behind custom commands. What is the risk?
- 41. A component has many UI states. Should all be e2e tests?
- 42. A test waits for an API and passes. What is missing?
- 43. A failed CI run has no screenshot or video. What do you improve?
- 44. A fixture has hundreds of unused fields. What is the problem?
- 45. What makes a Cypress answer senior?
Cypress Fundamentals
Foundational15 questionsStart here. These are the definitions and first-principle checks that open most rounds.
Q1. What is Cypress used for?
Cypress is used to test web applications through browser-based end-to-end and component tests.
It is especially common in JavaScript front-end teams.
Cypress changes Cypress decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Watch a deeper explanation
Video: Introduction to Cypress.io (Naveen AutomationLabs, YouTube)
Q2. What is the Cypress command queue?
Cypress commands are queued and run asynchronously by Cypress, not immediately like normal JavaScript statements.
This is why returning and chaining commands matters.
command queue changes Cypress decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q3. What does Cypress retry automatically?
Cypress retries commands and assertions until they pass or time out.
This reduces many fixed-wait problems.
automatic retry changes Cypress decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q4. What does cy.get do?
cy.get queries the DOM for elements matching a selector.
Use stable selectors and scope the query when possible.
cy.get changes Cypress decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
| Answer part | What to say | Evidence to mention |
|---|---|---|
| Definition | cy.get in one direct sentence. | Official docs or course material |
| Use case | The work where it changes a decision. | Dataset, model, query, dashboard, or pipeline |
| Risk | What breaks when it is misunderstood. | Metric, log, test result, or review note |
Q5. Why use should in Cypress?
should adds retryable assertions to Cypress command chains.
It waits for the expected condition within timeout.
should assertions changes Cypress decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Watch a deeper explanation
Video: Cypress Tutorial Full Course (Automation Step by Step, YouTube)
Q6. What are Cypress fixtures?
Fixtures are files that provide test data, usually JSON, for predictable test setup.
Use them when stable canned responses or data are useful.
fixtures changes Cypress decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q7. What is cy.intercept used for?
cy.intercept observes, stubs, or waits for network requests.
It is useful for checking API calls and controlling UI states.
cy.intercept changes Cypress decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
cy.intercept('GET', '/api/jobs', { fixture: 'jobs.json' }).as('jobs');
cy.visit('/jobs');
cy.wait('@jobs');
cy.contains('Frontend Engineer').should('be.visible');Q8. What are custom commands?
Custom commands wrap repeated Cypress actions behind reusable command names.
Keep them clear and avoid hiding important assertions.
custom commands changes Cypress decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q9. Why use cy.session?
cy.session caches and restores login state between tests where supported.
It can speed up suites while keeping setup explicit.
cy.session changes Cypress decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q10. What is Cypress component testing?
Component testing mounts UI components in isolation and tests their behavior.
It sits below full browser workflow tests.
component testing changes Cypress decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q11. What is test isolation in Cypress?
Test isolation means each test starts from a clean state and does not rely on previous tests.
Hidden order dependencies create flaky suites.
test isolation changes Cypress decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q12. Why are Cypress screenshots and videos useful?
They provide failure evidence from CI and local runs.
Artifacts help triage without rerunning immediately.
screenshots and videos changes Cypress decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q13. How does Cypress actionability affect clicks?
Cypress checks whether an element is visible, not disabled, not covered, and ready before acting.
This prevents some false clicks, but can expose real UI timing issues.
real events changes Cypress decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Watch a deeper explanation
Video: How to Write First Test Case in Cypress (Automation Step by Step, YouTube)
Q14. When should you stub network calls?
Stub network calls when you need deterministic UI states or want to test front-end behavior apart from backend availability.
Use real APIs when integration behavior is the goal.
network stubbing changes Cypress decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q15. What Cypress limitations should you mention?
Cypress has constraints around multiple tabs, cross-origin flows, and non-web platforms compared with some tools.
Modern Cypress supports more cross-origin cases than older versions, but constraints still matter.
Cypress limitations changes Cypress decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Cypress Practical Interview Questions
Intermediate15 questionsThese questions test whether you can apply the topic to real data, real code, and messy constraints.
Q16. How would you write a Cypress login test?
Visit login, fill email and password, submit, then assert a logged-in screen or user-specific element.
Do not only assert the URL.
write login test changes Cypress decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
cy.visit('/login');
cy.get('[data-cy=email]').type('qa@example.com');
cy.get('[data-cy=password]').type('secret');
cy.get('[data-cy=submit]').click();
cy.contains('Dashboard').should('be.visible');Q17. How do you choose Cypress selectors?
Prefer stable test IDs, roles, labels, or visible text tied to user intent.
Avoid styling classes and brittle DOM paths.
choose selectors changes Cypress decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q18. How do you wait for an API call?
Use cy.intercept with an alias, trigger the action, then cy.wait on the alias and assert the UI result.
Waiting for the API alone is not enough. Assert the user outcome.
wait for API changes Cypress decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q19. How do you test an empty state with Cypress?
Stub the API response with an empty list, visit the page, and assert empty state copy and actions.
Fixtures make empty states easy to reproduce.
test empty state changes Cypress decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q20. How do you test an API error state?
Intercept the request with an error status, then assert the visible error message, retry action, and no stale data.
Error states are often missed in UI suites.
test error state changes Cypress decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q21. How do you use fixtures well?
Keep fixture data small, named by scenario, and close to the behavior being tested.
Large generic fixtures become hard to maintain.
use fixture changes Cypress decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q22. When would you create a custom command?
Create one for repeated setup or domain actions such as login, but keep test assertions visible.
Over-abstracted commands make failures hard to read.
create custom command changes Cypress decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q23. How do you debug a Cypress failure?
Use the runner, command log, screenshot, video, console logs, network view, and narrowed reproduction.
First decide if it is product, test, data, or environment.
debug failure changes Cypress decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q24. How do you run Cypress in CI?
Install browsers and dependencies, run the chosen spec group, save screenshots, videos, and reports, then publish failures clearly.
CI should make failure action obvious.
run in CI changes Cypress decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q25. How do you split Cypress suites?
Separate smoke, critical path, component, full regression, and slow or quarantine tests.
This keeps feedback fast.
split suites changes Cypress decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Watch a deeper explanation
Video: Cypress Tutorial for Beginners (Testing Mini Bytes, YouTube)
Q26. How do you avoid logging in through UI for every Cypress test?
Use API login, cy.session, or controlled auth setup when the test does not specifically cover login.
Keep at least one UI login test.
handle auth changes Cypress decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q28. How do you avoid cy.wait with fixed time?
Wait on visible UI state, route alias, or assertion that represents readiness.
Fixed waits are slow and still flaky.
avoid fixed wait changes Cypress decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q29. How can Cypress support accessibility checks?
Run targeted accessibility checks in important flows and assert keyboard and visible-label behavior manually where needed.
Accessibility checks should not replace human review.
check accessibility basics changes Cypress decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q30. How do you keep Cypress tests maintainable?
Use stable selectors, clear spec names, focused assertions, small fixtures, shared setup, and regular flaky test cleanup.
Maintenance is part of automation quality.
maintain tests changes Cypress decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Cypress Advanced Scenarios
Advanced15 questionsAdvanced rounds test trade-offs, failure modes, and whether the decision can hold up under production pressure.
Q31. A Cypress test uses cy.wait(5000) and still fails. What do you change?
Replace fixed time with a retryable assertion or route alias that represents the real ready state.
Waiting longer is rarely the best fix.
flaky fixed wait changes Cypress decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q32. A UI class rename broke many tests. What is the lesson?
Use stable test attributes or user-facing selectors instead of styling classes.
Styling should not be the test contract.
class selector broke changes Cypress decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q33. A test passes with stubbed responses but production fails. What happened?
The test verified front-end behavior but not real integration.
Keep separate tests for real API contracts or smoke paths.
intercept hides bug changes Cypress decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q34. Every spec logs in through UI and the suite is slow. What do you do?
Use session or API setup for most tests and keep a small number of UI login checks.
Test setup should match the behavior under test.
slow login setup changes Cypress decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q35. A Cypress test passes only after another test runs first. What is wrong?
The test depends on shared state.
Make setup explicit inside the test or beforeEach.
test order dependency changes Cypress decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q36. A fixture no longer matches the API contract. How do you prevent this?
Review fixtures, add contract checks, and keep mock data minimal.
Mocks need ownership.
API returns stale fixture changes Cypress decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q37. A payment or auth flow crosses domains. What do you consider?
Check Cypress cross-origin support, decide test scope, and use API or sandbox setup where browser flow is not stable.
Some third-party flows are better covered by contract or sandbox checks.
cross-origin flow changes Cypress decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q39. A Cypress test passes locally but fails in CI. What do you check?
Check browser version, viewport, environment variables, network, timing, data, screenshots, and videos.
CI is a different environment.
CI-only failure changes Cypress decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q40. A framework hides every action behind custom commands. What is the risk?
Tests become hard to read and failures become harder to trace.
Use commands for setup, not to hide all intent.
too many custom commands changes Cypress decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q41. A component has many UI states. Should all be e2e tests?
No. Test many visual and interaction states in component tests, then keep a few full workflow checks.
Use the right test layer.
component vs e2e changes Cypress decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q42. A test waits for an API and passes. What is missing?
It must assert what the user sees or what state changed.
Network success alone does not prove UI behavior.
network wait without UI assert changes Cypress decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q43. A failed CI run has no screenshot or video. What do you improve?
Configure screenshots, videos, reporter output, and logs for failure triage.
Evidence reduces rerun waste.
dashboard artifacts changes Cypress decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q44. A fixture has hundreds of unused fields. What is the problem?
It is hard to maintain and can hide what matters in the test.
Use small scenario-based fixtures.
large fixture file changes Cypress decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q45. What makes a Cypress answer senior?
It covers command queue, retry behavior, selector contracts, network strategy, isolation, artifacts, and flake ownership.
Senior candidates explain why tests stay trusted.
senior Cypress answer changes Cypress decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Cypress vs Playwright vs Selenium
These tools overlap, but the design choices are different. A good answer compares fit, not popularity.
| Tool | Best fit | Strength | Trade-off |
|---|---|---|---|
| Cypress | JavaScript teams testing web apps | Great local debugging and retry behavior | Browser and multi-tab patterns need care |
| Playwright | Cross-browser web automation | Chromium, Firefox, and WebKit support | More setup choices to manage |
| Selenium | Long-running enterprise browser suites | Wide language and ecosystem support | Needs more framework decisions |
| API tools | Endpoint checks below the UI | Fast business-rule validation | Doesn't prove browser behavior |
Cypress interview topic weight
Cypress rounds usually test practical JavaScript automation skill.
Scale: Hyring editorial score for interview preparation, not an external benchmark.
- Selectors: stable test IDs
- Retry model: command queue
- Intercepts: network control
- Dashboard: nice to know
How to Prepare for a Cypress Interview
Prepare by writing one Cypress spec for login, one with cy.intercept, and one component test. Be ready to explain why each assertion proves the behavior.
- Practice cy.get, contains, should, within, fixture, intercept, request, session, and custom commands.
- Use stable selectors such as data-cy or data-testid instead of CSS classes tied to styling.
- Understand Cypress command queue and automatic retries. It changes how you write assertions.
- Prepare a CI answer: browser choice, artifacts, screenshots, videos, reports, tags, and failure triage.
Cypress test design flow
In Cypress, a clear assertion usually beats extra waiting.
What Strong Cypress Answers Prove
Strong Cypress answers show that you can write readable tests and keep them stable as the front end changes.
| Topic | Weak answer | Strong answer |
|---|---|---|
| Waiting | I add wait 5000. | I assert on the state Cypress should retry until it appears. |
| Selectors | I use CSS classes. | I use stable test IDs, roles, or user-facing labels. |
| Network | I mock everything. | I decide when to use real API, intercept, fixture, or contract check. |
| CI | I run Cypress in pipeline. | I publish screenshots, videos, reports, browser version, and failure owner. |
Test Yourself: Cypress Quiz
Ready to test your Cypress knowledge?
6 questions, about 4 minutes. Score 70% or higher to earn a shareable certificate.
Frequently Asked Questions
What do Cypress interviews usually ask?
Is Cypress better than Selenium?
Do Cypress interviews require JavaScript?
What Cypress project should I discuss?
What is the biggest Cypress interview mistake?
Is there a Cypress quiz?
Practice Cypress answers before a QA automation screen
Hyring's AI Coding Interviewer and AI Video Interviewer can test both code and explanation. Use this page first, then rehearse selectors, intercepts, and flaky test answers under time pressure.
Try AI coding interview prepSources
Written by Adithyan RK