Cypress Testing: How It Works, Where It Struggles and Why Teams Move to Playwright

Cypress testing means testing a web app with Cypress, an open-source JavaScript framework that runs your tests inside the browser, alongside the app itself. That design gives front-end developers fast feedback and a debugging experience they like, and it's also behind most of Cypress's limits: one browser at a time, no native multi-tab support, Safari coverage that's still experimental and no native mobile apps.

QA Wolf's position is simple: start new suites in Playwright. There's nothing Cypress does that Playwright can't do better, and Playwright handles the flows Cypress makes hard: a second tab, a sign-in on another domain, two users at once and Safari's WebKit engine. If your team is deeply invested in Cypress, keep it running for now, write new tests in Playwright and start migrating.

Stuck maintaining a Cypress suite? Xima had 200+ Cypress tests and a developer assigned full-time to keep them running. QA Wolf converted them to Playwright, covering 95% of Xima's workflows, and its developers got 20% of their week back. See how QA Wolf's managed test automation service works, or book a demo.

What is Cypress testing?

Cypress testing is writing and running automated tests for a web application with Cypress, a free, open-source (MIT-licensed) framework whose tests are written in JavaScript or TypeScript. Cypress's documentation describes four kinds of tests it runs:

• End-to-end tests load your app in a real browser and click, type and navigate the way a user would. Cypress was first built for these.
• Component tests mount one React, Angular, Vue or Svelte component in a real browser and test it on its own, without the rest of the app.
• API tests send HTTP requests with cy.request() and check the status, body and headers, in the same specs and CI job as the UI tests.
• Accessibility checks run on top of the other tests, through community plugins such as cypress-axe or Cypress's paid Cypress Accessibility product.

Cypress comes as two products. The Cypress App is the free, open-source tool you install in your project to write and run tests, on your own machine or headless in CI. Cypress Cloud is a hosted service that records CI runs and adds Test Replay, flaky-test tracking, pull request reports and parallel runs, with a free plan and paid tiers.

Cypress bundles Mocha to structure tests and Chai for assertions. If you searched for the "Cypress Testing Library," that's a separate community plugin that adds Testing Library's queries, so tests can find elements by their text, label or role, the way a user would.

How does Cypress work?

Cypress runs your test code inside the browser, in the same run loop as the app under test, with a Node.js process alongside it that launches the browser, routes its network traffic and handles anything the browser can't do. Cypress doesn't use Selenium.

That design shows up in day-to-day use:

• Direct access to the app. Tests can read anything in the page, stub functions and timers, and intercept or fake network responses, with no protocol in between.
• Commands are queued, then retried. Each Cypress command joins a queue and runs in order. Queries and assertions retry until they pass or time out, so you don't write sleeps or manual waits. It also means Cypress code reads like synchronous code but doesn't run that way, which takes new users time to get used to.
• Time-travel debugging. In the Cypress App, every command appears in a Command Log with a snapshot of the page, so you can step back through a test or open the browser's DevTools.
• Server work goes through Node. Seeding a database or calling a backend script happens through cy.task() or cy.request(), because test code running in the browser can't import server-side modules.
• Clean state for every test. By default, Cypress clears the page, cookies and storage before each test, so one test can't leak into the next.

What is Cypress used for?

Cypress is used to test the web app a team builds itself, usually by front-end developers who want fast feedback while they code. Cypress's own docs call testing your own application its "sweet spot," and point to other tools for crawling the web, performance testing and scripting third-party sites.

Teams pick it for:

• Tests in the app's own language. Front-end teams keep JavaScript or TypeScript tests in the same repo as the app. Playwright does too, and adds Python, Java and .NET.
• Component tests. Developers test a React, Angular, Vue or Svelte component in a real browser before it's wired into a page. Playwright has component testing too.
• Fast local feedback. The Cypress App re-runs tests when you save a file, and the Command Log shows each step. Playwright's UI Mode does the same, with watch mode and a step-by-step trace.
• Hosted CI reporting. Cypress Cloud adds Test Replay, flaky-test tracking and per-branch reports as a paid service. Playwright's HTML report and Trace Viewer come free with the runner.

Where does Cypress struggle?

Cypress struggles where a test has to leave the single browser tab it runs in: new tabs, second users, other domains, Safari, native mobile apps and, at scale, parallel runs outside Cypress Cloud. Cypress documents most of these as deliberate trade-offs of running inside the browser, with workarounds for some.

Can Cypress test multiple tabs?

Cypress has no native multi-tab support: it controls one browser at a time and has no built-in way to switch tabs or windows. Its docs point to the @cypress/puppeteer plugin, which works in Chromium-family browsers only and runs Puppeteer code you write in your Cypress config. For flows with two people, such as a chat or an approval, Cypress recommends stubbing the other side or driving it from your server instead of opening a second browser. That leaves "open in new tab" links, sign-in pop-ups and real-time collaboration as the flows that take the most work.

Can Cypress test across domains?

Cypress can test across domains, but only with extra work. Each Cypress test is bound to one origin (scheme, host and port), so a test that leaves your app, such as signing in through an identity provider on another domain or paying on a hosted checkout page, has to wrap the steps on the second domain in cy.origin(). Cross-origin iframes aren't supported, and cy.origin() doesn't work yet in Cypress's experimental WebKit mode.

Does Cypress support Safari?

Cypress supports Safari's engine, WebKit, only as an experiment. Its full support covers Chrome-family browsers (Chrome, Chromium and Edge) and Firefox; WebKit is an experimental option you turn on in config and install from Playwright's WebKit build. Cypress lists cy.origin() and Cypress Cloud's Test Replay among WebKit's known issues. If many of your users are on Safari, that's a real gap in your cross-browser testing.

How does Cypress run tests in parallel?

Cypress runs tests in parallel through Cypress Cloud. Its built-in support for parallel testing splits a suite by spec file across CI machines, and it only works on runs recorded to Cypress Cloud. The free Starter plan includes 500 recorded test results a month, according to Cypress's pricing page in November 2026, and when an organization reaches its plan's limit, Cypress turns parallelization off until it upgrades or the next cycle starts. A 200-test suite that runs on 20 pull requests a month records 4,000 results, eight times the free allowance. Open-source plugins such as cypress-split can spread specs across CI machines without Cypress Cloud, but you set that up and maintain it yourself.

Can Cypress test mobile apps?

Cypress can't test native mobile apps: its FAQ says it "will never be able to run on a native mobile app." It can test mobile web: you can set the viewport to a phone's size, and hybrid apps built to run in a browser (with Ionic, for example) can be tested there. Native iOS and Android apps need a mobile framework such as Appium, XCUITest or Espresso, compared in QA Wolf's guide to mobile testing frameworks.

What else is hard in Cypress?

• Languages other than JavaScript. Test code runs in the browser, so Cypress supports JavaScript and TypeScript only.
• Hover. There's no native hover command; Cypress documents workarounds.
• Iframes. Same-origin iframes can be queried, but there's no command to switch into an iframe.
• WebSockets. Connections work during tests, but Cypress can't stub individual messages.
• Maintenance at scale. This one isn't specific to Cypress. Any large end-to-end suite breaks as the product changes, and flaky tests pile up when nobody owns fixing them. GUIDEcx had a small set of Cypress tests that, in its Head of QA Operations' words, were "flaky and unreliable," and "the maintenance alone is more than one person can really handle."

How does Cypress compare with Playwright and Selenium?

Cypress runs inside the browser and supports only JavaScript and TypeScript; Playwright and Selenium drive the browser from outside, which lets them handle several tabs, users and domains in one test, and both support languages beyond JavaScript.

• Playwright is open source, from Microsoft. It drives Chromium, Firefox and WebKit through one API, with tests in JavaScript, TypeScript, Python, Java or .NET. One test can open several tabs and several isolated browser contexts (two signed-in users, for example), and the free test runner runs test files in parallel and can shard a suite across CI machines. It emulates mobile devices but doesn't test native apps, and its UI Mode and Trace Viewer give it a step-through debugging view of its own. QA Wolf's Playwright vs Cypress comparison goes deeper on architecture and speed.
• Selenium is the oldest of the three. It implements the W3C WebDriver standard, which works with every major browser, Safari included, and has official bindings for Java, Python, C#, Ruby and JavaScript. Selenium Grid spreads tests across machines. It also takes the most assembly: you choose the test runner, assertions and reporting yourself. Appium brings the same WebDriver approach to native mobile apps.
• Cypress is known for its local developer experience and an all-in-one install for JavaScript teams, with Cypress Cloud as a paid CI dashboard. Playwright's UI Mode and Trace Viewer now give the same step-through view, and Cypress still gives up native multi-tab and multi-user testing, full Safari coverage and native mobile.

QA Wolf recommends Playwright for web testing: it does what Cypress does and handles the flows Cypress can't, with parallel runs at any size and no paid service. Selenium still suits teams whose tests have to be in Ruby, or who already run a WebDriver grid.

What are the alternatives to Cypress?

Playwright is the alternative QA Wolf recommends. Selenium and WebdriverIO are the other open-source options.

• Playwright is the natural move for a JavaScript team, with the same auto-waiting and broader browser, tab and language support. QA Wolf's Playwright testing guide covers how it works.
• Selenium has the widest language and browser support, with more setup.
• WebdriverIO is a Node.js framework built on WebDriver that also automates native mobile apps through Appium.

If you'd rather not maintain the suite yourself, QA Wolf's agents write, run and maintain it in open-source Playwright. The tests are standard code your team owns and can take anywhere, with no lock-in.

How do you migrate from Cypress to Playwright?

Migrate flow by flow, with both suites running in CI until the Cypress one is empty:

1. Write every new test in Playwright. The Cypress suite stops growing on day one.
2. Move your critical flows first: sign-up, login, checkout and the workflow your product exists for. Retire each Cypress spec once its Playwright version passes in CI.
3. Translate the patterns, not line by line. Cypress's chained cy.get() commands become awaited locators such as getByRole(), cy.intercept() becomes page.route(), cy.request() becomes Playwright's request fixture, cy.session() becomes a saved storageState, and custom commands become fixtures or helper functions.
4. Turn on what Cypress couldn't do. Add the WebKit (Safari), multi-tab and multi-user tests your Cypress suite skipped, and run the whole suite in parallel.

QA Wolf's agents can do the migration for you: they start from your Cypress tests and rebuild them in Playwright, critical flows first, as they did for Xima.

Why does QA Wolf write tests in Playwright instead of Cypress?

QA Wolf writes every web test in Playwright because its customers' critical flows regularly cross the lines Cypress draws: new tabs, several users, other domains, browser extensions and downloads. QA Wolf compared both frameworks when it built its platform and chose Playwright because it controls the browser from outside the page, so those flows need no workarounds.

What that means for a team moving off Cypress:

• Flows Cypress makes hard are standard. According to QA Wolf's docs, its web tests cover multi-user workflows across several sessions, flows that move across domains, browser extensions, file uploads and downloads, drag-and-drop and canvas interfaces.
• The tests are yours. QA Wolf's AI agents write the tests as standard Playwright code (Appium for mobile and Windows desktop apps), so your team can read, change, version and run them like any other code, and take them with you.
• The whole suite runs at once. On QA Wolf's parallel test infrastructure, every test runs in its own container, so a run finishes in about the time of its longest test, whether the suite has 200 tests or 20,000.
• Only real bugs reach you. When a test fails, QA Wolf's agents work out whether it's a real bug or a broken test. Broken tests get fixed, real bugs are reported, and when an agent needs a question answered, it asks your team.
• You don't start from a blank page. QA Wolf starts from the Cypress tests you already run, along with your test plans and priorities, and builds your highest-priority and most complex flows first.

After GUIDEcx moved its end-to-end testing from its Cypress suite to QA Wolf, its tests run on every build and its bug tickets dropped 75%, according to its case study.