Complete Intro to React, v3 (feat. Redux, Router & Flow) Test Coverage with Istanbul
This course has been updated! We now recommend you take the Complete Intro to React, v8 course.
Transcript from the "Test Coverage with Istanbul" Lesson
[00:00:17] It's kind of for free. So we can do yarn test yarn test -- --coverage.
>> Brian Holt: And it's going to run our test with, let's see. Let's just make it so you can see the nice table.
>> Brian Holt: It's gonna output this nice line of like, this is how much you're covering your file with tests.
[00:00:43] So with search.jsx we got a 100% test coverage, it's hitting literally every line of Jest. ShowCard? We got 80% of it. A 100% of branches and 0% of functions. So, just by importing ShowCard, we're kinda validating ShowCard is probably at least going to not have any syntax errors right?
[00:01:06] But we really haven't tested much more than that. And then it's saying all files that the test suite knows about, we have 88% coverage of statements which is pretty cool.
>> Brian Holt: Furthermore what you can do is you can actually cd into this coverage directory that I created for you.
[00:01:22] And you can go into the lcov-report.
>> Brian Holt: And then you can say open index.html. This is, let's say I can make this a little bigger for you. This is an auto generated report from Istanbul. So I can click into ShowCard and I can see, it's like hey this never got run, right.
[00:01:47] This part in here, this red par. But, I at least saw this, I at least saw this, right.
>> Brian Holt: And then you can come in here to search.jsx. And this is something that I think is pretty cool for you to see. If you look down here on line 28, this got run 60 times just in the span of our little tests, right.
[00:02:15] That was for, yeah, all the various tests that we ran. So this lets you know, like this part right here, line 28, that's gotta be a pretty optimized code, because just with a couple re-renders, we ran this code 60 times.
>> Brian Holt: So this might even tell you something, like this particular toUpperCase business we're doing here.
[00:02:40] We should probably cache that, right? Because running toUpperCase with doing this template string a bunch of times, it could be a lot more performant. Especially if you're gonna be doing this a lot. So all this good stuff to know. Same with this map right here, 47 times, all things that you might wanna consider.
>> Brian Holt: Any questions? It's pretty cool, right? All this stuff we just got for free cuz Jest just does it for you. Which is coming from Istanbul, which is a pretty cool library. Another reason why I like Jest, cuz setting this up can be kind of a pain.
>> Brian Holt: So let's go just put that into our package.json, so we can have that kind of forever.
[00:03:30] So we're gonna do one more underneath test here, and it's gonna be test:coverage. And it's gonna be jest --coverage.
>> Brian Holt: So something that people tell me that I probably do too much is I put too much into the scripts part of package.json. There's no reason I can't just do yarn test -- --coverage.
[00:04:00] The problem is I forget this stuff all the time, right? If I don't run coverage very often, which to be honest with you I don't, I forget the name of that godamn parameter is. But it's really easy for me to open the package.json and say cool, here's all the stuff I can do.
[00:04:15] So that's why I put everything into here. So, something I wanted to kind of say is people take test covers to be like a gospel, like a core matrix of the code, and I think it's kind of bullshit in my opinion. Reason being is that this says that you have 80% test coverage of showCard.
[00:04:40] We have not tested a thing about ShowCard, all we did was import it. We haven't really validated anything that it's supposed to actually be doing. So this gives you good feelings about how much coverage you have about ShowCard and you should now have good feelings. You should not have them, because we're not testing it at all, right?
[00:04:57] So be extremely careful about how much faith you put into coverage. It's a good secondary metric, don't get me wrong. If you have high test coverage, that's a positive indication of things that you are doing, but because you have high test coverage, do not feel good about yourself, [LAUGH] right?
[00:05:15] That's all I wanna say.
>> Speaker 2: Functions column a little more reliable on that, would it show 0%?
>> Brian Holt: I'm gonna say no, I mean it's certainly not a good thing that it's 0%. But you could have a 100% function coverage and still not really be doing anything. Yeah.
>> Brian Holt: I mean, in this particular case where it's zero out of one. That is a strong indication that you're not actually really doing anything. But I can still see cases where you would have a be pretty high and still not really.
>> Brian Holt: So I would say, if we go back to that, this is a good way of deriving negative signals.
[00:06:03] So if these numbers are low, then you definitely have a problem, right? If they're high you might still have a problem. That's how I wanna phrase that.
>> Speaker 3: I think I just missed a step, how do you get to that screen on your browser?
>> Brian Holt: So if you go in here to your project,
>> Brian Holt: When you run coverage it generates this directory right there, right? So I just opened it in my browser. So you can go into cd coverage, and then it's lcov-report. And then, this is just a website that you can open. So I just said open index.html, which, that's a Mac thing.
[00:06:42] So if you're using Linux, but if you're using Mac that'll just open it in your favorite browser.