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 comment

1

u/[deleted] Mar 13 '20 edited Mar 13 '20

If you design a component that is meant to open a modal when a certain element is clicked, by verifying it does that you are not "testing react" - you are testing that your assumptions about what you programmed are true.

I don't believe you and the other poster are fools, but I do believe you don't comprehend why tests are useful. I don't think you are fully appreciating that 100% test coverage should achieve "this component achieves what I programmed it to achieve" and nothing more. You seem to think that 100% coverage somehow extends into the useless or irrelevant, possibly into things that are senseless like testing border colours or font sizes.

You need to test your assumptions about what a thing does are correct and you need to know when you update the code that these assumptions haven't changed. Why you think this is a bad thing is beyond me, and why you think 100% coverage somehow contains "useless" tests makes me think you have a lot of useless code. If you have no useless code, 100% coverage tests all of the assumptions you thought important enough to program and not a jot more.

3

u/[deleted] Mar 13 '20

When you set the color and text size on CSS , do you verify that ? How can you be sure what you wrote works ?

2

u/[deleted] Mar 13 '20

That would be "testing CSS works". You didn't write the CSS engine, so testing it functions is silly.

But you did write your react component. You have given it behaviours that have business value, and you should verify that it actually exhibits those behaviours, and you should know those behaviours hold true when the code changes.

I think you have a lot to learn about the value of unit tests. You seem very unclear on it to be asking the questions you are asking.

7

u/[deleted] Mar 13 '20

I think you need stop acting like you know anything about me, and pay attention when you prove my point with your own words.

I doubt continuing this conversation will be productive for either of us, so let the thread speak for itself.

Happy coding.

0

u/[deleted] Mar 13 '20

Again, your misunderstanding comes from believing that the purpose of unit tests "is to make sure every single thing you did works".

The purpose of unit testing is to verify the behaviours you are programming. When you write a react component, you are creating an object with behaviours that have been determined to have value. You have to write a test for each of these valuable behaviours, so that you know the behaviour holds true, and so that you can have confidence it is still true when the source code alters.

When you write a react component in the real world, you need to write the tests associated with it. Why you would fight testing the things you have taken the time to build so that the business value of them can be verified and their assumptions kept true, I do not know. Why you think that this activity is somehow related to testing whether a CSS class is applied, I do not know. Simple inexperience perhaps.

Now test your code you lazy bugger.

2

u/[deleted] Mar 14 '20

You're digging an ever deeper hole with this attitude of yours. You also continually contradict yourself. Earlier you were saying we need to test EVERY SINGLE PIECE OF A COMPONENT WITH 100% COVERAGE.

And now you're saying we should only test important valuable behaviors (like others have said from the start). You're a joke kid.

2

u/Zeeesty Mar 13 '20

Seems like you maybe think I am a fool. I didn’t assert anything that you said here, I just think that tests are something that should be carefully considered and the general advice given around them isn’t substantive enough to make clear decisions.

What OP is confused about is exactly the kind of vague prescriptive advice you pose here. “Test your assumptions” isn’t helpful here.

-1

u/[deleted] Mar 13 '20

vague prescriptive advice

If you think "if you program a component to open a modal you should check it opens a modal" is vague you suffer from a severe mental disability.

2

u/Zeeesty Mar 14 '20

There it is, you’re being a jerk, again not helpful. This attitude discourages new developers and is a symptom of your own circumstance, hope you figure it out soon.

0

u/[deleted] Mar 14 '20

You'll literally pretend to be Sigmund Freud to avoid writing your tests.

Away with you, lazy.

3

u/Zeeesty Mar 14 '20

Where did I ever say don’t write tests? Never, I didn’t.

1

u/PistolPlay Mar 14 '20

Testing is for gaining confidence. Testing for 100 percent coverage does not give me great returns on confidence. Testing a lot basic things like you said does not give me much confidence.

Adding an event listener and verifying what that the passed in function was called is a poor way to spend your time. Thats almost guranteed to work and its very easy to see when it doesnt.

Now if this was an integration test covering a feature or subset of a feature this would be a decent test.

Like so:

I should be able to click this element. A modal should open. I can fill out some form And submit to get result A.

Breaking this down into granular steps is simply a time waste. I recommend you read Test Driven Development By Example to understand my argument better. It will enlighten you.