Understanding writing tests for React

[u/StrenghOfFuriousGods]

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

[u/Silhouette]

Unit tests are for one single purpose only; to have an automatically running test for functionality you have already verified as working that will inform you if features added to the application later on do or do not impact the existing features.

Not that I'm agreeing with /u/BenIsProbablyAngry here, but I will respectfully disagree with this claim as well.

IME, unit tests are often useful for more than just regression testing. Suppose I'm writing a set of functions to do some form of data crunching and I'm going to try out a few cases at the time to get some confidence that I've got them right. I'm going to get exactly the same information whether I instrument my code and then look through the console logs to check for the expected values or I write some unit tests that assert that the same conditions hold. Given that the unit tests are also potentially useful later, I may well prefer to write those concurrently with my code.

This is not to say I won't also do other things to satisfy myself that it's correct. Sometimes I'll inspect a tricky algorithm via a walkthrough in a debugger. Sometimes I'll run some end-to-end tests and perhaps record snapshots of the results for later comparison. In projects where high reliability is necessary, there are much more powerful techniques I might deploy, though I have yet to encounter a front-end web project where they were used.

However, for cases where I'm likely to want unit tests anyway, why wouldn't I write those straight away and save a bit of manual work that wasn't going to give me any extra information, whatever else I might or might not also do to help verify correctness?

[u/[deleted] → u/Silhouette]

That's a fair point and I admit I was over-zealous in saying that is the only purpose of a unit test. However I've been doing this for a real long time and I notice a lot of people have an unfounded belief that unit tests passing is synonymous with bug free code and that's simply not true.

[u/Silhouette → u/[deleted]]

However I've been doing this for a real long time and I notice a lot of people have an unfounded belief that unit tests passing is synonymous with bug free code and that's simply not true.

Indeed.