What is the difference between using `react-testing-library` and `cypress`?

Question

So, react-testing-library is used for unit/integration testing, and cypress is used for e2e testing. However, both appear to do the same thing:

react-testing-library

• Facilitates mocking
• Tests as a user would
• Starts with the top-level component (not a hard and fast requirement, but if you don't you end up with a bunch of duplicate test cases in your sub-component testing)
• Instant feedback, fast

cypress

• Facilitates mocking
• Tests as a user would
• Starts with the top-level component (the page)
• Delayed feedback, slow, but provides extra tooling (video proof, stepping through tests, etc.)

Aside from the feedback cycle, they appear to be almost identical. Can somebody clarify what the differences are? Why would you want to use both?

Longobard

after almost a year, do you have some more clarity on the issue? It's definitely quite confusing unless you know both libs in detail – Stallion

I have used both libraries extensively, and I still don't have any new insights. Things appear to me as they always have. The primary difference appears to be the feedback loop/tooling, for whatever that is worth. Pick your favorite? In most cases I can't see why using both would be required (maybe smoke testing deployments with Cypress while doing other testing with RTL?). I still struggle with RTL, as the duplicate test issue I mentioned in the comments seems to constantly rear it's head unless you restrict your tests to "page level" tests (and even then there is grey area). – Longobard

Ther is a cypress’ biased comparison engineering.udacity.com/… – Weld

Answer 1

You've answered your question in the first line. If you want to test your React app end-to-end, connected to APIs and deployed somewhere, you'd use Cypress.

react-testing-library's aimed at a lower level of your app, making sure your components work as expected. With Cypress, your app might be deployed on an environment behind CDNs, using caching, and its data could come from an API. In Cypress you'd also write an end-to-end journey, a happy path through your app that might give you extra confidence once you've deployed.

Fiord

Yes, but the part that is bugging me about react-testing-library is that you can use it for testing individual components, but then you will need to essentially duplicate those tests when you go to test the higher/page level components. If you only use react-testing-library for testing page level components to prevent duplication and cypress does all that and more (can be used for mocked local tests, deployed to server tests, etc.), why use react-testing-library at all? It has the one benefit of fast feedback, but I'm not seeing any others. – Longobard

I should preface this by saying I'm not a developer, but I would imagine fast feedback and running fully local, independent of other connections / APIs are its main selling points. You would also write many more tests at a lower level than you would in Cypress, because the latter are more "expensive" in terms of time and resources. – Fiord

Appreciate the responses! You can mock out the external APIs and other things in cypress just like you would in react-testing-library, so I don't really see the benefit there. I understand your point about writing lower-level tests in react-testing-library, but the problem with lower-level tests is that it will likely lead to duplication when somebody goes to test at a higher level. For example, if I had component A which I tested and then I put it in component B, I would need to duplicate the tests for A in B. Does that make sense? – Longobard

You don't have to duplicate tests for A & B. In B you will just test it from the perspective of integration with A, and for any custom functionality. That's how I see it. – Millais

I guess you still need to spin up a webserver for cypress to run, so can never be quite as quick as a low level Dom test that doesn't require a full app server ? – Equanimous

Answer 2

Here's an article from Kent C. Dodds answering your question.

My personal take is that the best bang for the buck tests is Cypress E2E tests. This is especially true if you are new to testing and/or at the beginning of a project.

As the project grows, there will come a point where it makes sense to add some extra safety nets with integration tests to make sure certain complex parts of your frontend work. RTL is a better tool for these, runs faster and you can get more granular with it.

And finally, rarely, when you have some specific non-trivial logic, e.g. some complicated transforming of some complicated API data, then unit it.

Also RTL plays really nicely with Mock Service Worker and Storybook. You might not feel it's worth it for either of these tools alone, but put them together and wow you have an amazing, robust testing/documenting/sandboxing system in place!

Superintendent

Answer 3

• As Cypress is designed for both E2E testing and unit testing, according to the requirement we can do E2E testing or unit testing. So, there is no need to follow separate libraries for the two types of testing.

But in RTL, it is designed to test the application UI and interactions of the components. That means if we need to ensure the components are rendering and behaving correctly, we can use RTL. But for E2E testing, need to go with Cypress or a suitable library.

• Cypress can be used to test more advanced scenarios, like interactions with APIs or databases. But it is more difficult to test with RTL.

• Cypress is better for robust testing solutions because it provides more advanced features than RTL.
Ex: - Visual testing, time-travel debugging, and network stubbing.

In the case of RTL, it provides lightweight testing solutions. As it can be easy to set up into the testing workflow, if someone wants to do simple test scenarios like validate UI it is better to use RTL.

• In Cypress, it creates an end-to-end journey through the application. So that improves the developer confidence after deployment.

Ronrona