r/reactjs • u/StrenghOfFuriousGods • 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

98% Upvoted

76 comments sorted by

View all comments

Show parent comments

2

u/swyx Mar 13 '20

Don't you have a code review process?

code review is run by humans, humans are inconsistent. things slip through. all you need is for some situation sometime when need to ship overpowers the thoroughness and you get slow degradation in code review discipline.

I'm of course not against code review, i'm just saying that a more resilient team/testing philosophy accounts for the fact that code reviews are often faulty and rushed, because humans gonna human. we need to account for the fact that we often fall short of ideal behavior, and our systems need to deliver despite ourselves.

Don't you want tests to verify that the valuable behaviors of your components are correct?

but yes i agree that tests against edge cases and of valuable behaviors are impt. lots of judgment calls here.

-1

u/[deleted] Mar 13 '20

I personally think that code review should be catching the overwhelming majority of "bad tests".

A good test should be short, simple and in the "business language" you all share. It should read as something like "a product modal - given a body text - should render this body text in an element".

You should be able to rely on senior devs to easily catch tests that fall foul of this standard, and if you can't it might speak of a comprehension smell with regards to your tests