// 6 picks · reviewed August 2026
The Best Open Source End-to-End Testing Frameworks in 2026
End-to-end testing means driving a real browser — clicking, typing, waiting for things to render — and asserting on what a user would actually see. The four general-purpose picks here (Playwright, Cypress, Selenium, Puppeteer) all do this from Node or another language; what separates them is how much they do beyond that. Playwright and Cypress ship a full test runner with assertions and parallelism built in. Selenium and Puppeteer don't — Selenium is a cross-language protocol implementation, Puppeteer a Chrome-focused library other tools are usually built on top of.
The other two picks aren't competing with those four at all. If you're writing Elixir or Rust, your framework choice is mostly already made — Wallaby for Phoenix apps, fantoccini if you need WebDriver from async Rust — and the real question is what you give up by not being in the JS ecosystem.
How we picked these
Every repo here was read and assessed on its own before it was considered for this page: we pull the README, the directory layout and a key source file, and write the assessment from those rather than from the project's own marketing. Candidates for this list came from a full-text and topic search over the 36 reviewed repositories that matched this category. Anything with no commit in the last 12 months was cut, as were link collections, tutorials and boilerplates; the floor for inclusion was 300 stars. The ordering is a judgement call about who should pick what, not a ranking by stars. finds.dev is independent of every project listed here: nobody paid for a place on this page, there are no affiliate or referral links on it, and we have no commercial relationship with any of them. That is the point of writing down what each one is bad at as well as what it is good at.
// 1 of 6
★ 95,251 · TypeScript · Apache-2.0 · updated Aug 2026
teams that want one framework across Chromium, Firefox, and WebKit with a built-in test runner, parallelism, and CI tooling
Playwright is the default answer now — one API across Chromium, Firefox, and WebKit, with a test runner, parallelism, and trace viewer built in rather than bolted on afterward. Auto-waiting and web-first assertions kill most of the flaky sleep() calls that haunt older Selenium suites, and Trace Viewer is one of the few debugging tools in this list that's actually useful in CI, not just on your laptop.
The cost is that Microsoft ships cross-browser support by patching Firefox and WebKit itself rather than driving the unmodified browsers — so "cross-browser" here means "as far as Microsoft's patches allow," and you're waiting on their cadence to catch upstream security fixes. The project has also split into three overlapping things — test runner, standalone CLI, MCP server — plus a VS Code extension, so the README now reads like a routing page more than documentation for one tool. If you just want scriptable browser control without a test runner's opinions, Puppeteer is lighter; if you want the same breadth of engines without Microsoft's patches in the loop, that tradeoff doesn't really exist elsewhere on this list.
View on GitHub → Our full take →
// 2 of 6
★ 51,003 · TypeScript · MIT · updated Aug 2026
JS/TS teams that want the best local debugging experience and a time-travel test runner
Cypress still has the best moment-to-moment debugging experience here — the command log and time-travel UI let you click back through a failed test and see the DOM at each step, a different kind of feedback loop than reading a Playwright trace after the fact. It's also the most production-tested codebase of the bunch: separate driver, server, and reporter packages, dogfooded against its own Cypress Cloud on every PR.
What you give up is Safari — Cypress doesn't support it at all, which rules it out if your users are meaningfully on iOS. Multi-tab and multi-origin testing, which Playwright handles natively, still trips people up in Cypress migrations. Component testing quality also depends heavily on which framework adapter you're using; React and Angular are well maintained, others noticeably less so. And it's a genuinely large codebase to contribute to — building the binary and running the full suite locally is not a weekend project.
View on GitHub → Our full take →
// 3 of 6
★ 34,404 · Java · Apache-2.0 · updated Aug 2026
polyglot teams needing Java, Python, C#, or Ruby bindings, or already running Selenium Grid
Selenium earns its spot for one reason: it's the only framework here with mature bindings across Java, Python, C#, Ruby, and JS, all built on the same W3C WebDriver spec, so behavior is genuinely consistent language to language. If your org is polyglot or already running Selenium Grid at scale, nothing else on this list replaces that infrastructure.
If you're greenfield and JS-only, there's little reason to start here over Playwright — auto-waiting and modern debugging tooling arrived in Selenium later and less cleanly than in the newer frameworks. The build is heavy: Bazel plus a toolchain per language plus a custom Rake wrapper, which the project's own docs admit is rough on Windows. And flakiness in downstream suites is inherent to how old and general the core is — Selenium can't fix that for you the way Playwright's auto-waiting tries to.
View on GitHub → Our full take →
// 4 of 6
★ 95,512 · TypeScript · Apache-2.0 · updated Aug 2026
teams that just need scriptable Chrome/Firefox control, not a full assertion/test-runner layer
Puppeteer isn't really competing with the others as a test framework — it's the library most of them build on top of. If what you need is scriptable control of Chrome (screenshots, PDF generation, scraping, request interception) without a test runner's opinions about assertions and fixtures, this is lighter than Playwright and more current than raw DevTools Protocol calls.
The catch is that it stops at browser control — no built-in test runner, no assertion library, no parallelism story; you wire that up yourself or pick a framework that already did, which is most of this list. The postinstall Chromium download is now routinely blocked by npm/pnpm/yarn's script-blocking defaults, so new users hit silent failures until they learn to run `puppeteer browsers install` by hand — a support burden that shows up constantly in the issue tracker. And despite BiDi support, Firefox is still second-class next to Chrome, so verify any cross-browser claim against the specific feature you actually need.
View on GitHub → Our full take →
// 5 of 6
★ 1,797 · Elixir · MIT · updated Apr 2026
Elixir/Phoenix teams testing their app in a real, concurrent browser session
If you're testing a Phoenix app, Wallaby isn't competing with Playwright or Cypress — it's the only option that understands Ecto's SQL sandbox, threading the sandbox token through the browser's user-agent header so concurrent tests each get their own database transaction without serializing the suite. That's a genuinely hard problem solved cleanly, and the blocking query API — poll until it appears, no sleep() — gives you the same anti-flakiness Playwright chases, just in Elixir.
It only drives Chrome, directly or through Selenium — no Playwright engine, no WebKit, no way to test Safari rendering at all, and unlike the JS frameworks, Wallaby has no fallback story here. WebAuthn and passkey testing is bolted on via raw CDP calls with no real helper API, so any test touching passwordless auth ends up looking like a copied JSON blob. And the project has gone quiet — last real activity was mid-2024, with open Chrome-compatibility issues sitting for months, which matters more here than it looks given how fast ChromeDriver has to track Chrome's release cadence.
View on GitHub → Our full take →
// 6 of 6
★ 2,012 · Rust · Apache-2.0 · updated Jun 2026
Rust teams driving a browser over WebDriver from native async code
For Rust, fantoccini is less "best in category" and more "the only serious option" — a clean, fully async WebDriver client built on tokio, with locator chaining that reads naturally and error types that actually tell you what went wrong. Jon Gjengset maintaining it is a real signal, and unlike some entries here, its CI runs against real chromedriver and geckodriver rather than mocks.
It's a client, not a framework — you bring your own geckodriver or chromedriver process and manage its lifecycle yourself, something Playwright and Cypress handle invisibly. There's no trace recording, no screenshot diffing, no network interception — the things Playwright users take for granted don't exist here, and waiting on async page mutations in a modern SPA will push you past what wait.rs covers. Fine for scripts and straightforward e2e suites; expect to write your own tooling for anything more elaborate.
View on GitHub → Our full take →
Questions people ask
Should I use Playwright or Cypress in 2026?
If you need real cross-browser coverage including Safari, go with Playwright — Cypress doesn't support Safari at all. If you value the moment-to-moment debugging experience, clicking back through a failed test's DOM live, Cypress still wins that specific comparison. For a new JS/TS project without strong opinions either way, Playwright covers more ground out of the box.
Is Selenium still worth learning in 2026?
Yes if you're polyglot — Java, Python, C#, Ruby — or already running Selenium Grid, since nothing else here matches its cross-language consistency. For a JS-only greenfield project, Playwright or Cypress get you to a working suite faster with less flakiness out of the box.
What's the difference between Puppeteer and Playwright?
Puppeteer is a browser-control library; Playwright is a full test framework built on the same idea, plus a test runner, assertions, and support for Firefox and WebKit. Pick Puppeteer when you don't want a test runner's opinions and just need scriptable Chrome control, Playwright when you do.
Do Wallaby and fantoccini compete with Playwright?
Not really — they exist because Playwright has no official Elixir or Rust bindings. If you're in Phoenix or async Rust, they're the practical choice regardless of what wins in the JS ecosystem, and Wallaby in particular solves database isolation for concurrent browser tests in a way nothing on this list attempts.
None of these is universally right — pick based on your stack and how much test-runner opinion you want baked in, not on star count. If you'd rather have picks like this land in your inbox every week instead of hunting for them yourself, that's what the finds.dev email does.
Get finds like these weekly →