What are some good reasons to use Cypress over Playwright in a new project? or is it game over for Cypress?
The main reason there are lots of articles about Playwright is it's newer and solves some issues people have with E2E testing in Cypress (like multi-tab support) and is more idiomatic JS (using async/await instead of how Cypress does it, which is waiting for each `cy` command to finish before running the next one (it queues them up and runs each one sequentially, so await/async isn't required)).
Cypress has also invested heavily in the developer experience; it has a UI that shows all the commands that executed, and lets you do "time travel" debugging, where you can go back and see the state of the test/DOM after each Cypress command ran. From what I can tell, Playwright is more focused being a solid, cross browser automation tool first. I'm not aware of any kind of interface that exists that is similar to Cypress (I haven't kept up; it's possible something similar exists).
As far as the tools go, Cypress has a lot of opinions and recommendations about how best to use the tool; Playwright seems less opinionated. Some people like tools that come with a lot of guide rails; other people prefer to take a tool and use it how they want.
Another thing to consider is target user; a lot of JS engineers who understand async/await well will have no problem with Playwright; some QA engineers I've worked with who don't come from a JS background found the Cypress API more intuitive.
To answer your original question "What are some good reasons to use Cypress over Playwright in a new project" - I think if you value the Cypress interact runner with the snapshots and command log, or if you value the style of test that the Cypress API encourages (take a look at API) it's a good choice. If you prefer a less opinionated tool, or you value certain features Cypress doesn't have (multi-tab, etc) Playwright might be a better fit.
> ... defending a sunk cost, rather than than advocating for the best API ...
If you really go all-in on the Cypress API, writing custom commands, etc, not having to mess around with async/await is really nice. It's a strong point for onboarding QA devs, who might not be familiar with JS, Promises etc. This is also one of the major drawbacks - for any proficient JS devs, who are used to async/await and the usual business, the obvious question is "why isn't this just standard JS?". I definitely had the same feeling when I first starting writing Cypress tests.
> It would be hard for Cypress to change the API now ... I doubt Cypress team would design the API this way if they started again today ...
I am not sure of the technical complexity or priority of decoupling Cypress from the Chainable API. I'd assume the complexity is not supporting async/await, but supporting it alongside the current API.
I think the ideal case would be loosening the coupling between all the parts of Cypress, that would allow someone (either the Cypress team or a third party) to write their own selecting/assertion API, and they could then optionally write it with chaining, async/await, or something else. Perhaps even create bindings for another language (currently Cypress is JS only, since a lot of the code executes in the browser, unlike Playwright, where everything is via the CDP - another example where one of the main strengths of Cypress can also be a weakness).
Hopefully this gives you some more context and insight! My goal is better testing tools for the web, I think both Cypress and Playwright are solving this problem in different ways with a different philosophy. I'm glad to see so much innovation in the space, I hope we can keep pushing things forward.
Really just depends on what your testers are more comfortable with in the abscence of developer willingness to contribute. 99% of the time, iny experience, Devs just don't.
I can tell you that Cypress did a very bad job imo at getting across their architecture, and what it ultimately was they were trying to make, and they went out of their way to (again, my opinion) debug the framework itself. They don't have any onboarding docs to help ease a dev from another language into the JS world, and to help get a debugger attached such that you can build up an intuition for the framework.
Imagine you're new to NodeJS. Now you need to work through:
-How yarn or js tooling spawns off processes like hotcakes. -How to get the debugger even attached to the right thing -once there, trying to figure out how to navigate the quirks of JS. -you've got to become aware of the CJS/ESM divide, and get to grok how TS is basically pre-CJS dressed up to look more safe to peeps coming from OO. -You have to get through the Electron barrier, which is like nodejs, but just different enough that you have to activate the debugging functionality slightly differently, and the build chain for OSX is a pain. -Then you have to reason through Babel/WebPack which justifiably scares the crap out of people.
It also suffers from being in a language most developers dread, because if you haven't made that Functional leap yet, it's a wench. There is also the problem that frontend devs will write genuinely bad frontends that break under a consistent test runner, then blame the failing test on being a problem with the test runner. The flakyness of JS's build systems, and the fact the environment has 1 million and 1 dependencies to read through to wrap your head around "okay, wtf is going on" doesn't exactly help, and intimidates most groups of backend devs trying to figure out why a test is acting weird.
The test runner is fine, your UI practices are just terrible. You'll run into the same problems with Playwright, but that'll probably not be as opaque (maybe) to your devs, so it's an easier pill for them to swallow when they read it.
You'll still be kicking yourself at the stupidity of writing the same tests over again if you get an idiot clamoring to move off it and such, which as a test maintainer, your most powerful weapon is "you want it? You maintain it and integrate it into the Quality pipeline. To my spec."
Either they grumble and go away, or they get inspired to suddenly really care about testing and Quality, a topic that groups are terrible at. Either way, win-win.
I brought in Cypress, no one could be bothered to read the code. I read the code. Mostly grok it enough to realize nobody is really getting away from anything, and have made Cypress do things it was not designed or intended to do.
(I.e. Cypress is equally capable at being a mock driven UI exerciser, and a performance tester if you set the response timeout expectations low enough).
You can literally get three suites out of 1 codebase. Though again, it's almost guaranteed no one else will want to read enough to actually help you get there... And to make things worse, they've gone in the direction of graphql, which introduces a level of hair pulling and 'nope' even I'm getting pause at. Because if anything gives me the warm fuzzies, it's totally the Cartesian product waiting to happen that is GraphQL in the hands of the uninitiated. GraphQL itself being a bit of a polarizing topic amongst architects in my experience.
...Probably not strictly what you asked for. In fact, I may have made the other guy's case... The main point to take out of it though, is they both do the same damn thing, they both get better with actually reading the thing, and literally the pnly thing Playwright has going for it is the transpilation layer to other languages.
Use what your testers and your stack can most easily accommodate. You aren't shooting yourself in the foot with Cypress, but you may not make a lot of friends on dev teams either. Also, ignore service providers hawking wares, which many articles probably are, or someone trying to justify a framework that lets them write in the language they want to write in in order to avoid learning domething new/different.