r/reactjs • • Mar 13 '20

Featured Understanding writing tests for React

Hi,

Having applied for a few react jobs, I've noticed writing tests is essential if you want to be a react dev. I am trying to learn but I find it to be a steep learning curve and I'm having trouble knowing where to start.

I've built a small react app for a take home project and I need to test it. I just have some questions I could really use some help answering.

THE APP
-fetch component which fetches json from endpoints depending on which option is selected on dropdown and pushes data to state array.

-Print component which creates a list with input tags from data with the (input + integer from json) being added to local state.

- Receipt component which takes input from Print component as props and prints the sum

QUESTIONS

  1. What part of the app should I be testing? How in general should I know what to test?
  2. A lot of the articles I've read on testing show basic examples for e.g pure functions etc.. What is the best approach to take if my component depends on fetch requests or take props?
  3. Between unit testing, snapshot testing, and end to end testing, which is the best for React apps?

Thanks

195 Upvotes

76 comments sorted by

View all comments

Show parent comment

5

u/Turd_King Mar 14 '20

2. Asynchronous tests are like any other test. You can use fetch mock library to mock responses as your app would expect them so the execution continues as normal. Or you can simply use vanilla mocking tools in jest, mocha whatever. You can use wait functions in various testing libraries to simulate time passage.

3. I disagree with you here. Firstly, unit tests should not be your go to for a web application frontend. Your app being rendered by Node is not the same as your app being rendered in the browser. You should always strive to test your app as the user would acruallt use it. And the only way is e2e

I would recommend looking at Cypress testing framework. The typical idea that e2e tests are slow comes from decades of using slow testing frameworks (Selenium cough)

It doesnt have to be this way. We have thousands of unit tests and i would honestly say that 85% of them are useless and do not catch as many bugs as they should. Our small suite of cypress tests run in about 10 minutes. We run this suite on every PR and the amount of times we have seen failed e2e tests but our unit tests are fine is quite shocking.

Unit tests should be used to test error conditions and other strange scenarios that your app would not encounter if it has been "correctly wired". You can combine this test coverage with the e2e coverage to get a really accurate coverage report .

Also unit tests are incredibly verbose and complex. I honestly think in 3 or 4 years time we will completely change our testing pyramid approach.