Closed Vadorequest closed 3 years ago
Changes:
experimentalComponentTesting
must be removed (component testing will use a different command)experimentalInteractiveRunEvents
should be added@cypress/react/support
import should be deleted, seeTag me in a comment if you need any help upgrading. I know of one issue with next.js and CSS modules, but other than, I think it should be a fairly smooth upgrade.
Thanks for proposing your help, I've started working on #327 and met a few issues. As you know I've opened https://github.com/cypress-io/cypress/issues/16471 but haven't tried fixing those issues based on feedback I got there. I'll try fixing this and if I run into other issues I'll ping you there directly then! 😃
Merged!
The component support will come later, if ever.
@lmiller1990 Someone asked an interesting question regarding Cypress vs react-testing-library, I was wondering if you had any feedback about that. 😄
Also, my understanding about Cypress's future is that it tries to grow in the "Testing market", what was first an E2E-only test framework is growing. Do you have any feedback/info you could share about that? I'm interested in the direction it's heading, and wondering how/if it should be used alongside other testing libs.
I replied to the other question in the other thread.
As for the direction Cypress is heading - yep, we started as a tool focused on e2e testing. The main goals:
The alternatives in this space are the many web driver based tools, like Selenium, and more recently Puppeteer.
As people came to enjoy Cypress for e2e, the next logical step is "can I use it for component tests, too? Those run in a browser, like my e2e tests". The answer was "kind of". With the way e2e works in general, you compile your app, spin up a server, and run your e2e tests against it. This doesn't work so well for components, since you generally want to skip the compile step and just use something like webpack hot reload. So you could do it, but it wasn't really the optimal experience.
With this in mind, we rearchitected part of Cypress for component testing. The component testing runner uses the same driver/runner/network layer, but we also use a dev server (either webpack or Vite), so you can skip the re-compile step. It gives you a much faster feedback loop than previously, comparable to tools like storybook. You can see just how much faster it is here.
As for other testing libraries, you can use the testing library driver if you like - we have an integration here. You won't be able to use Jest, though - that's a node.js based test runner, and Cypress needs to run in a browser - that's the whole point of Cypress, testing in a browser, as close to production as possible.
That's not really a problem in practice, since Cypress bundles mocha/chai for testing, and we have our own (very powerful) network layer, cy.intercept
.
Hopefully that helps!
Thank you for the explanation, and the video is very interesting, too.
It confirms what I thought already, keep using Jest for business/algorithms, and use Cypress for integration tests. I was a bit lost about "Component unit" tests (use Cypress? Or react-testing-library? Or X?)
I understand now it can be done using Cypress (officially since v7), it's still unclear what I should use, because I haven't done much "component unit tests" so far, and I don't have much experience with those libs, so I can't tell what's the best (for me) comparing Cypress vs react-testing-library and other "component unit tests" libs. If you know of any resource that gives some kind of overview with pros/cons that'd be great!
Regardless, using the same technology for integration and component unit tests makes more sense to me, it's very similar (they're both "user stories", basically user workflows) and using the same lib is probably easier from a dev standpoint (don't have to learn yet another lib and syntax).
If you don't need component tests, you don't need them. A lot of people can get away with just some basic unit tests with Jest for business logic, and E2E tests.
If you have a lot of complex components, working on a design system, or something that has a lot of complexity in React/Vue etc, you might benefit from the more granular component tests. Cypress is good, since you can actually see what's happening. Testing Library in the terminal + Jest can be good too, especially if you are already used to it.
I will try and do a more formal blog post talking about the differences and doing a fair comparison. If I end up writing that, I'll share it here :)
Awesome, I'd love that!
I understand your point, unless react-testing-library, Cypress components units tests are visual. That's the key difference because it might be much easier/faster to understand what's wrong when things fail to match our expectations.
As for "do we need it"? I think we do, as NRN is meant to be a boilerplate providing great DX and all the must-have tooling for building production-grade apps.
I'd agree. We are still in alpha for component testing, but I am using it for all my new apps and loving it. I'm not too biased either; I maintain Testing Library's Vue integration, and I enjoy using Testing Library as well. The Testing Library integration with Cypress is good too, if you like the opinionated philosophy of Testing Library but the visual aspect of Cypress.
https://docs.cypress.io/guides/references/changelog#7-0-0
Need to analyze what breaking changes will affect NRN.
If you'd like to use v7, please share us why (to speed-up migration). 😄
Resources:
Issues: