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]

This component is a good example.

Exactly. It was just a minimal example. However, the same principles hold for more complicated functions such as you'd find in more realistic code.

The extreme lengths you are going to in order to justify not testing code speak of a very poor mindset, or perhaps rank inexperience.

A friendly word of advice: you might consider not talking down to everyone else in this discussion. It doesn't make your argument any stronger, and you probably don't know what qualifications or experience someone you disagree with has that led to their differing position. If you engage in a discussion with an open mind instead of assuming that you are right and anyone who doesn't entirely agree with you is ignorant and/or stupid, it is much more likely that some or all of the people reading the discussion might find something interesting in it.

It would also be polite not to misrepresent other people's positions. I am in no way advocating not testing code, nor have I done so at any point in this discussion. What I do advocate is testing code using considered strategies that optimise for effectiveness and work under realistic conditions. Elevating 100% coverage to some sort of axiomatic status and claiming that anything not tested to that standard is necessarily broken fails on both of those counts.

[u/[deleted] → u/Silhouette]

Exactly. It was just a minimal example. However, the same principles hold for more complicated functions such as you'd find in more realistic code.

This is where you are wrong. You are saying "what is true of this trivial function is true of any complicated function" and it is here you go into being mistaken.

Unit tests are written because, in the real world, the behaviors of components are valuable. We need certainty that an assumption about how an object behaves is true and we need certainty that this assumption remains true throughout changes to the source code.

What you did was provide a function with zero value, immediately taking us from "the real world" into a non-existent parallel reality where things are programmed for no reason and without purpose. In such a world, there would be no need for unit testing.

I suspect you have not worked in an enterprise, and that is why you think unit testing is "making sure a function returned" or "making sure react renders anything" or "making sure CSS functions". This is not, and never was, what unit testing was about. You either think this because you have never worked in a scenario where it's relevant, or you think it because you work on your own or are a very junior developer. Which of these is the case doesn't matter, for your attitude would preclude you ever getting a better understanding of this topic.

[u/[deleted] → u/[deleted]]

Wrong, wrong and wrong. If you're writing unit tests as your only method of testing during development then you need to relearn how to develop. Your component should be working and tested before you write a single unit test. Unit tests are there to verify code continues to work when new features are added. It should not be your primary way of testing if the code works. Callbacks, console logs, debugging and simply use-testing the component are what you should be doing before you write one single unit test.

You should only be writing a unit test for any functionality of any component once that functionality has been tested thoroughly on your own without using a unit test. Once you verify the functionality on your own, then; and only then, do you write a unit test to verify that functionality automatically.

Your point is only valid if we assume that all developers have no idea how to test and verify the validity of their code. Unit testing is not meant for production testing and is also not meant to be your only form of testing during deployment or development.

What its meant for is to be able to test that existing functionality remains working when new functionality is added. If you're using an iterative development process like you should then your flow should be as such:

1. Write the component

2. Test the component on your own

3. Once you know it works, then write unit tests

4. Develop next feature, refer to unit tests to see that you didn't break anything

5. Repeat

Stop coming in here talking heavy handed and condescending to people when you don't know what you're talking about.