Testing React Apps in 2022 with Cypress: An In-Depth Guide for Beginners(profy.dev)
profy.dev
Testing React Apps in 2022 with Cypress: An In-Depth Guide for Beginners
https://profy.dev/article/cypress-react
39 comments
I came here to say that, too! Thanks.
(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.)
[1]: https://playwright.dev
(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.)
[1]: https://playwright.dev
Just tried this out. The user experience is really incredible. So much better than Puppeteer (not sure if it's really a valid comparison, though).
> invented their own non compliant promises spec
> that means you can’t use async functions
what does one thing has to do with the other, please elaborate
> the 1st party xpath... > runner doesn’t support individual tests...
seem minor
> sometimes return objects not wrapped objects
sounds like lodash chaining, which is fine once you understand the library
> the plug-in ecosystem is weak
big deal? I use a tool like cypress for itself, not plugins, whatever they do
I get it, the tool isn't perfect and has things you don't like, but I don't see how this warrants a "do not use", seems pretty disproportionate
what does one thing has to do with the other, please elaborate
> the 1st party xpath... > runner doesn’t support individual tests...
seem minor
> sometimes return objects not wrapped objects
sounds like lodash chaining, which is fine once you understand the library
> the plug-in ecosystem is weak
big deal? I use a tool like cypress for itself, not plugins, whatever they do
I get it, the tool isn't perfect and has things you don't like, but I don't see how this warrants a "do not use", seems pretty disproportionate
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.
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.
Running in the browser is a feature.
The endless polyfilling to make a node env removes some of the before of the test imo.
The endless polyfilling to make a node env removes some of the before of the test imo.
2022 one should not start a new project with Cypress. Playwright is simply so much better.
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?
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.
https://playwright.dev/docs/debug
https://playwright.dev/docs/debug
Playwright is nice and lightweight but bit barebones compared to Cypress, leaving you to decide for many things.
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 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.
[deleted]
Can you elaborate please on that? Just starting on a new project where they have used playwright, but I never tried it
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)
They have experimental support for safari: https://docs.cypress.io/guides/guides/launching-browsers#Web...
Why not use playwright?
https://playwright.dev/
Why not use playwright?
https://playwright.dev/
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).
Is playwright that much better?
It's pretty solid. Even cypress webkit is using playwright.
Does Cypress (or any other end-to-end testing tool) even care whether the web app is a "react app"?
No, it will interact with elements no matter which framework is used.
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.
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 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 appreciated this intro to Cypress, but does anyone know of a resource that takes a more advanced dive?
I’m looking for pitfalls, edge cases, special features, performance optimization, that kind of thing.
I’m looking for pitfalls, edge cases, special features, performance optimization, that kind of thing.
Their docs are surprisingly good: https://docs.cypress.io/guides/references/best-practices
Ooh, I had skimmed the docs but hadn’t seen the best practices section, thanks!
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...
Cypress is good if you need to emulate a user navigating through screens on a site.
React Testing Library is good if you want to unit test individual components.
They both have their uses.
React Testing Library is good if you want to unit test individual components.
They both have their uses.
Fyi with Cypress v10 and the new component testing feature you can do a lot of things that you'd usually to with RTL
Despite calling itself a unit test framework, RTL is actually component testing because it doesn't believe in shallow rendering.
It's a massive pain in the ass.
It's a massive pain in the ass.
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).
[0] https://youtube.com/playlist?list=PLC2LZCNWKL9bLQrMQKfTnpihg...
[0] https://youtube.com/playlist?list=PLC2LZCNWKL9bLQrMQKfTnpihg...
It's classic journey testing vs unit testing, and you should definitely do both.
Does anyone recommend a similar guide for playwright?
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.
https://playwright.dev/docs
https://playwright.dev/docs
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.