It’s got a lot of frustrating edge cases and problems that mean your tests will always be brittle and break. A short list of the issues I’ve personally found is:
- they invented their own non compliant promises spec that means you can’t use async functions or methods.
- the 1st party xpath plug-in is not fully implemented and fails to have a sub selector (get xpath in this element).
- the runner doesn’t support individual tests in the ui, only test groups
- the plug-in ecosystem is weak, and many plugins only work with “happy path” scenarios, meaning you have to fork them to fix bugs
- you can’t catch a failed promise and try something else (see stupid promises implementation) meaning it’s always a hack to have a fallback test
- I can’t even begin to describe how frustrating the ‘.wrap()’ api is. The people who wrote this used jquery as their programming model, and it shows. Every object gets a magical wrapper to use the magical cypress functions, but promises sometimes return objects not wrapped objects. Your code starts looking very familiar if you alias “cy.wrap” to “$”.
It’s pretty, it’s smooth for trivial tests. …but do you need trivial tests?
Probably, you don’t need trivial tests. For trivial things, you can use unit tests.
Cypress makes it easier to throw away your tests and write them again than it does to maintain the ones you have.
(Prefer other types of tests whenever possible, but if you really do need drive-the-entire-browser E2E tests, use Playwright[1]. It's years ahead of Cypress.)
Having worked as both a dedicated tester and a software developer, I've gotta say that Cypress was leaps and bounds above the alternatives before it, but nowadays Playwright is just better. Because Cypress runs in a browser context, it's very awkward to import Node modules and other reusable code where as Playwright makes it a breeze because it runs on the Node context (with ESM and TypeScript support natively).
If you're considering Cypress for test automation, I would really suggest giving Playwright a go. It fixed many of the pain points I had with Cypress. Even just tabbing in Cypress requires a plugin, where as it's supported natively in Playwright.
back when I was doing FE, I found https://codecept.io, which is the same concept as Cypress but with a Playwright driver. Have not used but thought it's worth a mention
Looks useful considering it supports other drivers such as web driver. I was considering cypress recently and now playwright but having the ability to utilize other systems (if one loses favor) seems nice.
Agreed. I started a project with Cypress a year ago (having used Cypress for more than a year at that time) but then had to switch to Playwright and have been quite happy with it 200 tests later. PW is able to do everything I needed from Cypress and has much better performance (easy parallelism and sharding) and has tracing/video recording in the free version. PW also uses regular JS promise versus the mysterious half-async-half-sync Cypress commands. A less mentioned distinction between the 2 is that Cypress also runs in the browser main thread and I’ve observed that this interferes with React 18 applications that use concurrent rendering so tests become unreliable (not the case with PW). One thing PW lags behind is the interactive test runner and I think they’re working on it.
I've been a long time Cypress user, but recently have been feeling those pain points you mentioned, the half-async-half-sync APIs are driving me mad :)
Im interested in Playwright, but wondering how you find the visual runner compared to Cypress? Are you able to run your tests in the browser and use a `debugger` or dev tools?
PW’s test inspector is pretty good. You can step through your test code and debug selectors. The inspector also runs in headed mode so you have the regular browser’s dev tools. The only thing left I want from PW is for PW to automatically rerun a test when it’s changed.
Cypress is also missing some pretty fundamental things, like tabbing through the document using the tab key. I don't know how people test for accessibility without this.
I haven't done JS for awhile, but according to https://docs.cypress.io/api/commands/type#Events they still don't support it. The docs point you to a third party package that tries to simulate it inside the page.
I will take this opportunity to ask: is there any way to make Cypress work with Safari? I saw they have experimental webkit support, but I don't know if that's Safari or the GNOME browser on Linux. (Maybe it doesn't matter, but we ran into something at work where we'd have a use for testing on older versions of Safari)
Because our tests are already written with Cypress and we don't want to change again (we just moved from Protractor after Angular said it was dying, so we've already rewritten them once).
We have used cypress from day one and I don't regret it. Would I use it again? Definitely no.
We're now in a situation where we have a test suite that we mostly disabled because of outdated tests vs function, all because cypress is hard to work with (see other comments).
Playwright is just better, has a tracing switch for in depth analysis and supports typescript right out of the box (playwright puppet :D).
Should you in the unfortunate case and need to use cypress, you can use https://sorry-cypress.dev/ !
Because cypress is/was open, someone just build a dashboard alternative to their business model.
Comparing React Testing Library with Cypress is comparing apples and oranges. They provide tools for writing different kinds of tests. React Testing Library is useful for testing React components, meaning: it is React specific, and it is used for writing unit tests.
However, Cypress is an end-to-end testing platform useful for any frontend application not just React apps. Also it is not useful for writing unit tests.
I don't have any strong opinion about the end-to-end testing tools though, but some mentioned Playwright is a better alternative if you are looking for e2e testing.
I’ve had a horrible time testing an app using a web socket backend. Cypress tests take forever to run, fail randomly due to race conditions, and websocket responses are annoying to mock.
I liked https://testingjavascript.com/ from Kent.C.Dodds a lot.
It has a separate chapter on Cypress testing.
Not sure if it qualifies as advanced, since he also start from scratch.
But Kent always has fast-paced videos, so you won't be skipping lots of sections...
I made some content showing how the new Cypress Component Testing can also handle things you might use RTL for [0]. You can evening use the TL finders (but I don’t in this series).
I have always found the Playwright docs themselves to be sufficient for all practical purposes. Common use cases all have individual guides on how best to perform them. For use cases that require some combination of results, the entire API is well-documented.
I can’t be clearer than that.
It’s got a lot of frustrating edge cases and problems that mean your tests will always be brittle and break. A short list of the issues I’ve personally found is:
- they invented their own non compliant promises spec that means you can’t use async functions or methods.
- the 1st party xpath plug-in is not fully implemented and fails to have a sub selector (get xpath in this element).
- the runner doesn’t support individual tests in the ui, only test groups
- the plug-in ecosystem is weak, and many plugins only work with “happy path” scenarios, meaning you have to fork them to fix bugs
- you can’t catch a failed promise and try something else (see stupid promises implementation) meaning it’s always a hack to have a fallback test
- I can’t even begin to describe how frustrating the ‘.wrap()’ api is. The people who wrote this used jquery as their programming model, and it shows. Every object gets a magical wrapper to use the magical cypress functions, but promises sometimes return objects not wrapped objects. Your code starts looking very familiar if you alias “cy.wrap” to “$”.
It’s pretty, it’s smooth for trivial tests. …but do you need trivial tests?
Probably, you don’t need trivial tests. For trivial things, you can use unit tests.
Cypress makes it easier to throw away your tests and write them again than it does to maintain the ones you have.