Cypress
JavaScript-first testing framework that runs in the browser. Excellent developer experience with real-time reloading and built-in assertions.
Overview
Cypress, launched in 2014, is a frontend testing framework that executes tests directly inside the browser rather than driving it externally like Selenium or Playwright. This architecture gives developers unique debugging capabilities including time-travel debugging, real-time reloads, and automatic DOM snapshots at every test step.
Cypress is particularly popular in React, Vue, and Angular teams where developers write their own tests. In NZ, startups and mid-size SaaS companies frequently adopt Cypress because of its gentle learning curve and excellent documentation.
What it's used for
Cypress shines when:
- Frontend developers own testing: The DX is optimised for developers who want to debug tests as easily as they debug application code.
- Component testing: Cypress 10+ added first-class component testing for React, Vue, Angular, and Svelte.
- Real-time feedback during development: The Test Runner UI updates instantly as you edit tests or application code.
- Stubbing and mocking: Easy network interception for isolating the frontend from backend dependencies.
Pros & Cons
Pros
- Time-travel debugging: hover over commands to see DOM state at that moment
- Automatic waiting: no explicit waits needed for elements, networks, or animations
- Excellent documentation and onboarding experience
- Built-in screenshot and video recording on failure
- Component testing for modern JS frameworks
Cons
- Only supports JavaScript/TypeScript — no Python, Java, or C# bindings
- Cannot drive multiple tabs or multiple origins in one test
- Firefox and WebKit support is experimental compared to Chrome
- Slower than Playwright for large suites due to in-browser architecture
- Cypress Cloud requires paid subscription for parallelisation and analytics
Platforms & Integrations
Cypress runs on Windows, macOS, and Linux. It primarily targets Chromium-based browsers (Chrome, Edge) with beta support for Firefox and WebKit.
Pricing
| Tier | Cost | Includes |
|---|---|---|
| Open Source | Free | Test Runner, all framework features |
| Cypress Cloud | $75/user/mo | Parallel execution, test analytics, flaky test detection, SSO |
NZ Context
Cypress is common in NZ startups and agencies building modern JavaScript applications. Companies like Pushpay and Vend (now Lightspeed) have used Cypress for their React-based UIs. The NZ JavaScript community hosts regular Cypress workshops. For teams where QA engineers don't write code, Cypress can be harder to adopt than no-code alternatives like Tosca or Katalon.
Alternatives
- Playwright — Faster, supports more browsers, and has better CI parallelisation.
- Selenium — Better for multi-language enterprise teams and legacy browser support.
- TestCafe — Similar JavaScript focus but with cross-browser support out of the box.
When to choose Cypress
A quick decision guide for NZ teams evaluating ui / e2e automation options.
| Choose Cypress when… | Choose something else when… | Combine with… |
|---|---|---|
| Your stack is React, Vue, or Angular and developers own the tests | Tests must run across Safari, Firefox, and Chrome with parity — Playwright's WebKit support is production-grade; Cypress's is still experimental | Jest or Vitest for unit and integration tests — Cypress handles the browser layer, Jest handles pure logic |
| The team needs time-travel debugging to diagnose flaky tests fast — critical when CI pipelines run unattended | Tests span multiple browser tabs or cross-origin iframes — Cypress's single-origin constraint will force awkward workarounds | Postman or REST Assured for API-layer tests — keep Cypress focused on UI behaviour rather than loading it with HTTP-only assertions |
| Small-to-medium suite (under ~500 specs) where in-browser isolation matters more than raw parallel speed | The team writes tests in Java, Python, or C# — Cypress is JavaScript/TypeScript only and cannot interop with those ecosystems | GitHub Actions matrix builds for parallelisation if Cypress Cloud's paid tier is out of budget — split spec files across runners instead |
| Component-level UI testing alongside Storybook — Cypress's component test runner mounts components in isolation without a full app server | Parallelisation at scale is a hard requirement and budget is tight — Playwright's open-source sharding beats Cypress Cloud on cost | Axe-core via cypress-axe for accessibility assertions — runs WCAG checks inside every Cypress test with one extra command |
What I would do
Practitioner judgment on tool adoption, team onboarding, and when to swap.
cy.origin() workarounds. The cross-origin iframe interaction is a first-class concern in the journey, not an edge case — Playwright handles it cleanly. I'd keep Cypress for the bank's internal React components where the time-travel debugger earns its keep, and let each tool do what it's best at.The bottom line: Cypress is the right default for JavaScript-native teams building single-domain SPAs — its developer experience genuinely reduces the time from "broken test" to "root cause found." The moment your critical user journeys cross origins or require non-JS languages, treat that as a hard signal to reach for Playwright instead.
Interview questions
Questions you are likely to get if you list Cypress on your CV — with what interviewers are really testing for.
What is the difference between Cypress and Selenium, and why would you choose one over the other?
What they’re really testing: Whether you understand the architectural difference between in-browser execution and WebDriver-based control, not just which tool is “newer.”
Strong answer covers: Cypress runs inside the browser process (giving it direct DOM access and automatic waiting), while Selenium talks to the browser via WebDriver over HTTP; Cypress only supports JavaScript/TypeScript whereas Selenium supports Java, Python, C#, and others; in a NZ team context, Cypress is the stronger choice when developers own the tests and the stack is React/Vue/Angular, while Selenium suits enterprise teams with existing Java or C# test infrastructure.
When would you use Cypress over Playwright for a new project?
What they’re really testing: Whether you can make a reasoned tool decision based on real constraints rather than defaulting to the most popular option.
Strong answer covers: Cypress is the better choice when the team needs time-travel debugging to get developers comfortable writing their first browser tests; Playwright is better when tests cross multiple origins, require non-Chromium browsers in production, or need open-source sharding at scale; in a NZ SaaS startup context, Cypress often wins for its onboarding experience, but a government project requiring NZISM-compliant cross-domain SSO flows would push you toward Playwright.
You’re a QA engineer at a NZ fintech. Your Cypress suite passes on your laptop but fails intermittently in GitHub Actions CI — how do you investigate?
What they’re really testing: Whether you have a systematic debugging process for flaky tests and understand the environmental differences between local and CI execution.
Strong answer covers: Enable Cypress video and screenshot recording in CI (video: true) to capture exactly what happened at failure; check for timing issues caused by slower CI hardware by reviewing whether cy.wait() calls or fixed timeouts are being used instead of Cypress’s built-in retry-ability; compare browser versions and viewport sizes between environments; use cypress run --headed locally to simulate CI; note that Privacy Act-compliant test data seeding (no real customer data in CI fixtures) can also affect test behaviour if seed scripts are environment-dependent.
How would you structure a Cypress test suite for a large single-page application with 50+ user journeys?
What they’re really testing: Whether you understand test architecture and maintainability concerns, not just how to write individual tests.
Strong answer covers: Organise specs by feature domain rather than by page (e.g. cypress/e2e/claims/, cypress/e2e/payments/); extract shared actions into custom commands (cy.login(), cy.seedCustomer()) rather than repeating setup in every spec; use cypress/fixtures/ for test data with environment-specific overrides; apply the testing pyramid — run component tests for most coverage and reserve e2e specs for critical happy paths; structure CI to run smoke specs on every PR and the full suite nightly, which keeps feedback fast without blocking developers.
Your Cypress suite takes 40 minutes to run and developers are skipping CI. What do you do?
What they’re really testing: Whether you understand the difference between speed and thoroughness, and whether you’ll reach for a paid solution first or exhaust engineering options.
Strong answer covers: First profile which specs are slowest using Cypress Cloud’s free test analytics or timing output, then decide: split spec files across GitHub Actions matrix runners (free, typically cuts time by 60–75%); move purely API-validating specs out of Cypress into a cheaper tool like Supertest; delete or demote low-value tests that check cosmetic details rather than behaviour; only reach for Cypress Cloud parallelisation after exhausting free options, since at NZ team budget levels (often 3–8 QA engineers) the $75/user/month cost is meaningful.