Intermediate React

Intermediate React Testing Philosophy & Q&A


This course has been updated! We now recommend you take the Intermediate React, v5 course.

Check out a free preview of the full Intermediate React course:
The "Testing Philosophy & Q&A" Lesson is part of the full, Intermediate React course featured in this preview video. Here's what you'd learn in this lesson:

Brian leans on his experience at Netflix to give his opinion on when to test your components. Brian tests his JavaScript modules, but rarely tests his UI because in his experience, the UI is always in a state of change.

Get Unlimited Access Now

Transcript from the "Testing Philosophy & Q&A" Lesson

>> Brian Holt: So that's gonna conclude our time on tests. Does anyone have any questions about tests?
>> Speaker 2: So with the fact that you were getting 16% coverage with the modal to actually properly test that would you have to, because you're importing it into the file that you are starting to test.

[00:00:21] Would you have to make another instance of the specific component or meaning the modal, or is there a way within there it has the relative use of it?
>> Brian Holt: So, the correct answer to your question would be that your Details.test.js should not test Modal.js. You should not rely on details to test modal.

[00:00:46] You should have a separate test for Modal.test.js that covers everything inside of Modal. So almost every component probably should have its own test. That kind of answer your question? Any questions from online, Mark? Or are we good?
>> Mark: What factors do you use to determine which components to test?

>> Brian Holt: That's a good question, so I'm going to give you a giant grain of salt about I do not have typical opinions about testing UIs. So take everything I'm about to tell you as an atypical response to this question, not reflective of the community. For the most part I try to tell you what the community thinks.

[00:01:31] In this case, what I think is I do not test my React components hardly at all. And the reason being is when I was working at Netflix for example, our UI was in such a state of flux. Every week we're pushing new components and new routes, and new things that we're constantly testing and refactoring all these kind of things so, our UI was constantly changing.

[00:01:51] So, spending any amount of time writing test for these would mean they're going to be throwing away next week, right? So I did not write every many tests for my React components. You might be in a different situation where you're like working at maybe like a bank or something like that where you're gonna write a component and it's gonna live for five years.

[00:02:09] In that case, yeah, you should go write some tests for that and make sure that all the functions work, but when I was at Netflix. We will be wasting time by writing too many tests for React components. So in my opinion the way that I do tests is I write multiples right, so I have maybe like an API module and I test the hell out of that.

[00:02:33] Because no matter what if I'm changing, UI components that API client's gonna live on, right? I'm gonna use that API clients, so I test all of my modules to exhaustion, I test like all the various branches, I try to have like a 100% test coverage on those things, right.

[00:02:47] All that error cases, all that kind of stuff. I might write some snap shot components for something like the The navigation or the header things like that. The footer. Things that are not changing too much. Then I was trying to have a couple like end to end tests on cypress or selenium, something like that.

[00:03:07] Those are so painful to maintain. You only want to have one or two that are extremely critical. This had covered things like, maybe if you're doing any commerce website that would be check out and add to cart like, very, very essential core things to your business. But I'm not gonna have a test that you can update your password, it's something that's less important.

[00:03:28] So, I wanna have the bare minimum amount of test that give me an assurance that if I go out, I'm not gonna break things, and that's generally testing modules. So if your components unless it's a long living component I tend not to test them very much. Unless I'm having a lot of bugs with one of them, and it is a long living component then I'll go write some more test, right?

[00:03:49] So I tend to write test that cover bug fixes as well. Generally because it helps me assure myself that I have fixed the bug.
>> Brian Holt: So that's kind of around about way of saying I don't test UIs very much.
>> Brian Holt: But I invite you to form your own opinion on the matter and like I said I'm against the community in this particular matter

>> Brian Holt: So that got us through testing with React. In previous versions of this course I've gone a little bit more into depth as well. If you wanna check that out, and I used Enzyme. Enzyme is a very common library used for testing React libraries. It's put up by AirBnB, it's really good.

[00:04:32] So if you want to learn how to use enzyme with just check out B3, everything from the previous version of complete [INAUDIBLE] in Frontend Masters has all of that in it.