--- title: "Cypress Testing: Where It Excels and Where Teams Outgrow It" excerpt: "Cypress made browser testing feel good to write, and that mattered. The constraints that push teams off it are architectural, not cosmetic, and worth understanding before you commit a suite to it." metaDescription: "Cypress testing in 2026: what it does well, the architectural constraints, cross-browser and tab limits, and when teams move to Playwright." publishedAt: 2026-07-30 author: Shiplight AI Team categories: - Guides - Engineering tags: - cypress-testing - cypress - e2e-testing - browser-testing - test-automation metaTitle: "Cypress Testing: Strengths and Limits" featuredImage: ./cover.png featuredImageAlt: "Illustrated Shiplight blog cover: a test runner executing inside the browser alongside the application, with a boundary marking what it cannot reach." --- Browser testing was miserable before Cypress. Tests were written against a remote driver, debugging meant reading logs, and the feedback loop was long enough that people avoided writing them. Cypress made the experience good, and a lot of suites exist today that would not otherwise. That contribution is real. So are the constraints, and they come from one architectural decision worth understanding before you commit. ## What it is **Cypress is an end-to-end testing framework that runs inside the browser, in the same run loop as your application.** Its runner shows tests executing step by step, lets you time-travel through them, and gives you the DevTools you already know. That in-browser architecture is where both the strengths and the limits come from. It is not a detail. ## What it does genuinely well **The debugging experience.** Watching a test execute with DOM snapshots at each step, then inspecting the failure with DevTools open, is still among the best in the category. When a test fails, you usually know why in under a minute. **Automatic waiting.** Commands retry until they succeed or time out, which removes the manual sleep calls that make naive browser tests flaky. **Low barrier to writing.** The API reads well and a frontend developer is productive quickly. Underrated: a framework people are willing to write tests in produces more tests. **Component testing.** Mounting a component in a real browser sits usefully between unit tests and full E2E, and Cypress does it well. ## Where the architecture constrains you Running inside the browser buys the debugging experience and costs the following. **Multiple tabs and windows.** Not supported in the way tests sometimes need. Flows that open a new tab, an OAuth popup, a payment window, a document preview, require workarounds rather than a direct expression. **Cross-origin navigation.** Historically painful and still more constrained than driving a browser from outside. If your flow crosses domains, expect friction. **Cross-browser depth.** Chromium and Firefox are covered. WebKit support has lagged, and WebKit is how you catch Safari-specific problems without owning Apple hardware. If a meaningful share of your users are on iOS Safari, this is the constraint that decides it. **Language.** JavaScript and TypeScript only. Fine for most frontend teams, a hard stop for a QA organization standardized on Python or Java. **Parallelism.** Achievable, but historically easier when paying for the vendor's orchestration, which is a different cost shape from a runner that shards on its own. None of these matter if your application is a single-origin Chromium-first web app. All of them matter eventually if it is not. ## When teams actually move The migration usually happens for one of three specific reasons rather than general dissatisfaction: - A flow that needs a second tab, and the workaround stopped being acceptable - Safari bugs reaching production that WebKit coverage would have caught - Parallelism costs at a scale that made the bill visible [Playwright vs Cypress](/blog/playwright-vs-cypress) covers that comparison properly. The short version: Playwright drives the browser from outside, which loses some of the in-browser debugging intimacy and gains tabs, origins, WebKit and a runner that parallelizes without a subscription. If none of those three reasons applies to you, a working Cypress suite is not a problem in need of solving. Rewriting tests that pass is a cost with no user-visible benefit. ## The constraint neither framework addresses Cypress and Playwright both give you a good way to write a test. Neither has an opinion on the thing that actually kills suites: tests bound to selectors that change. A test finding a button by CSS class works until someone renames the class. Multiply by a few hundred tests and one redesign, and the suite fails for reasons unrelated to whether the product works. The noisy tests get disabled to unblock a release, nobody re-enables them, and coverage decays while the dashboard stays green. This is getting worse rather than staying flat, because coding agents refactor and rename far more aggressively than cautious humans do. Selector churn rises at exactly the moment test volume does. [Shiplight](/plugins) works on that layer rather than replacing a framework. Tests are written as intent, transpiled to Playwright plus an AI SDK, and run in ordinary Playwright browsers. When a cached locator goes stale, the step re-resolves from intent against the current page instead of failing, and the heal appears as a reviewable diff. An existing Playwright suite keeps running alongside, so adoption is incremental. Honest scope: web applications, and this does not migrate a Cypress suite for you. ## Frequently Asked Questions ### Is Cypress still a good choice in 2026? For a single-origin, Chromium-first web application with a JavaScript team, yes. Its debugging experience is still among the best. The constraints are multi-tab flows, cross-origin navigation and WebKit coverage. ### Can Cypress test Safari? WebKit support has lagged behind the other engines. If catching Safari-specific problems matters to your users, this is the clearest reason teams choose otherwise. ### Why can Cypress not handle multiple tabs? It runs inside the browser alongside your application, which is what gives it the debugging experience and what prevents it from controlling a second tab directly. ### Should I migrate from Cypress to Playwright? Only for a specific reason: a flow needing a second tab, Safari bugs reaching production, or parallelism costs. A working suite is not worth rewriting on principle. ### Does Cypress do component testing? Yes, and well. Mounting a component in a real browser sits usefully between unit tests and full end-to-end coverage. ## Related Reading - [Playwright vs Cypress](/blog/playwright-vs-cypress): the head-to-head - [End-to-end testing](/blog/end-to-end-testing): what the layer is for - [Best Cypress alternatives](/blog/best-cypress-alternatives): the wider option set - [Locators are a cache](/blog/locators-are-a-cache): why suites decay regardless of framework