E2E Testing Frameworks & Tools: Playwright vs Cypress vs Selenium
Playwright vs Cypress vs Selenium: The Real Differences
Playwright (Microsoft, open source) runs tests against Chromium, Firefox, and WebKit from one API, auto-waits for elements without manual sleep calls, and parallelizes test runs out of the box. It's the framework most new E2E suites start with in 2026, and for good reason: less flaky-test debugging time, faster CI runs.
Cypress pioneered the developer-experience-first approach to E2E testing: time-travel debugging, automatic screenshots on failure, a UI that shows you exactly what the browser did. It's genuinely pleasant to write tests in. Its historical weakness was multi-browser support (Chrome-only for years); that's improved, but Playwright still edges it out for cross-browser coverage.
Selenium is the oldest of the three and the most language-agnostic — bindings exist for Java, Python, C#, Ruby, JavaScript, and more. Most new projects don't choose Selenium anymore, but plenty of large, established suites still run on it, and rewriting a mature test suite just to switch frameworks is rarely worth the risk.
| Playwright | Cypress | Selenium | |
|---|---|---|---|
| Speed | Fastest | Fast | Slowest |
| Multi-browser | Native (Chromium, Firefox, WebKit) | Improved, Chromium-first | Full (via WebDriver) |
| Debugging experience | Good | Best | Basic |
| Language support | JS/TS, Python, .NET, Java | JS/TS only | Nearly any language |
| Best for | New projects, speed-critical CI | Teams that value DX, existing Cypress suites | Legacy suites, non-JS teams |
Tomas inherited a 300-test Selenium suite at a logistics company in Warsaw when he joined as the third engineer. The suite took 45 minutes to run and flaked constantly. Rather than rewrite it — a multi-month project with real regression risk — he left Selenium in place and added a smaller, fast Playwright suite for the highest-risk checkout flows, running on every PR instead of nightly. Two frameworks, one CI pipeline, no rewrite.
Gomag, an e-commerce SaaS platform running 1,700+ active online stores, took the same incremental approach at larger scale — increasing release frequency 300x without a framework rewrite, just a change in what environment the existing suite ran against.
Point your existing E2E suite at a real environment per PR.
Playwright, Cypress, or Selenium — the framework doesn't change, only the base URL does.
E2E Testing vs Integration Testing: What Each One Actually Catches
These get confused constantly, and the confusion causes real gaps in test coverage.
Integration testing checks that two or more components talk to each other correctly — for example, that your payments service correctly calls your inventory service's API and handles its response. It's narrow, fast, and pinpoints exactly which integration broke.
E2E testing checks a complete user-facing workflow across every layer, from clicking a button in the UI through every backend service down to what actually lands in the database. It's slower and less precise about where a failure originated, but it confirms the system works the way a real user experiences it.
Neither replaces the other. A service can pass every integration test and still fail E2E, because the failure only shows up when three services interact in an order none of the pairwise integration tests covered. The practical split most teams land on: integration tests for individual service boundaries, a smaller set of high-value E2E tests for the critical user journeys (checkout, signup, core workflow) that actually matter to the business. Our end-to-end testing guide for microservices covers this split in more depth for distributed architectures specifically.
Testing React Apps: What's Different
React's async rendering used to be the single biggest source of E2E test flakiness. A test clicks a button, the assertion runs before React finishes re-rendering, and the test fails even though the app behaved correctly.
Playwright and Cypress both solved this with auto-waiting: they wait for the DOM to stabilize before asserting, instead of requiring a hardcoded sleep(2000) that either wastes time or isn't long enough. Selenium can do this too, but it takes more manual configuration (explicit waits, custom conditions) to get the same reliability.
For a React-heavy codebase specifically, this is one case where the framework choice matters more than usual. If your app is React and you're starting a new E2E suite in 2026, Playwright's auto-waiting behavior will save real debugging time over Selenium's more manual approach.
Testing AI-Generated Code: Same Tools, More Volume
Teams using Cursor, Copilot, or Claude Code don't need different E2E tools. Playwright, Cypress, and Selenium all work exactly the same against AI-generated code as they do against human-written code, because they're testing behavior, not authorship.
What changes is volume. AI-assisted developers open PRs faster, which means E2E suites run more often, against more environments, in parallel. A test suite that took 20 minutes and ran twice a day for a 10-person team now needs to run 15-20 times a day if that same team triples its PR throughput with AI assistance. The framework doesn't need to change. The infrastructure underneath — whether you have enough environments to run all those test suites in parallel without queuing — does. See how to test a pull request before merging for the full setup.
Common Setup Mistakes
Running the full suite on every commit. Full E2E suites are slow. Most teams run a small smoke suite (5-10 critical tests) on every push, and reserve the full regression suite for merges to main or a nightly run. This keeps CI fast without giving up coverage.
Hardcoded waits instead of auto-waiting. Every framework here supports proper auto-waiting. sleep(3000) calls are a sign the suite was written in a hurry, and they're the single most common source of flaky tests teams inherit from older suites.
No retry logic for genuinely flaky steps. Network calls fail sometimes for reasons that have nothing to do with your app. A single retry on network-related failures, not on assertion failures, catches this without masking real bugs.
Testing against a stale shared environment. This is less about the framework and more about the target. An E2E suite is only as trustworthy as the environment it runs against. If that environment has three other PRs' changes half-deployed onto it, a passing test doesn't mean much.
Picking Your Stack
If you're starting fresh in 2026 with no existing E2E investment, Playwright is the reasonable default for most teams: fastest, best multi-browser coverage, and it handles React's async rendering cleanly. Cypress is a fine choice if your team already knows it well or you value its debugging UI over raw speed. Selenium makes sense mainly if you're maintaining a large existing suite or need language bindings the other two don't offer.
Whichever framework you pick, none of them care where the environment they're testing against comes from. Point Playwright, Cypress, or Selenium at localhost, shared staging, or a fresh ephemeral environment per PR, and the test code doesn't change — just the base URL. The framework decision and the environment decision are independent, which means you can upgrade one without touching the other.
✅ Key Takeaways
- Playwright is the default choice for new projects: fastest, native multi-browser support, built-in parallelization
- Cypress has the best debugging experience but historically weaker multi-browser support (now improved, still behind Playwright)
- Selenium remains relevant mainly for legacy suites and language bindings the other two don't cover
- E2E testing and integration testing answer different questions — most teams need both, not one instead of the other
- None of these tools care whether they're pointed at shared staging or a fresh per-PR environment — that's an infra decision, not a framework one
FAQ
What is the best E2E testing framework in 2026?
Playwright leads for most new projects — fastest execution, native multi-browser support (Chromium, Firefox, WebKit), and built-in parallelization. Cypress remains strong for teams already invested in it, with the best developer experience for debugging. Selenium is the right call mainly for legacy suites or when you need language bindings Playwright and Cypress don't support.
What's the difference between E2E testing and integration testing?
Integration testing validates that two or more components work together correctly — for example, that Service A calls Service B correctly. E2E testing validates a full user-facing workflow across every layer, from the UI through every service to the database. Integration tests run faster and pinpoint failures more precisely; E2E tests take longer but confirm the system behaves the way a real user would experience it.
Does Playwright work well for testing React applications?
Yes. Playwright auto-waits for React state updates and re-renders, which eliminates most of the manual wait/sleep logic that plagued older E2E tools testing React apps. Cypress handles React well too, with a slightly different auto-retry model. Both outperform Selenium for React specifically because of how they handle the framework's async rendering.
How do you E2E test AI-generated code differently?
You don't need different tools — you need to run E2E tests more often and against more PRs, because AI coding agents raise PR volume 2-3x. The tools (Playwright, Cypress, Selenium) stay the same; what changes is the infrastructure underneath needs to handle running many more test suites in parallel without becoming the new bottleneck.
Can E2E testing tools run against a fresh environment for every pull request?
Yes — all major E2E frameworks just need a base URL, and that URL can point to a shared staging server or a freshly provisioned per-PR environment. Pointing them at an isolated per-PR environment instead of shared staging is a configuration change, not a tooling change.
Try Bunnyshell free.
Point your existing E2E suite, whichever framework you chose, at an isolated environment for every pull request.
