This course has been updated! We now recommend you take the Intermediate React, v5 course.
Transcript from the "Code Coverage" Lesson
[00:00:00]
>> Brian Holt: We're gonna add one more thing here which is gonna be test:coverage. And we're gonna do again jest --silent --coverage. There's another library that jest incorporates inside of it called Istanbul
>> Brian Holt: What Istanbul does code coverage reports for you. Which is it should be familiar to many of your developers out there, but if you are not familiar with it it's going to tell you how much of your code is covered by tests.
[00:00:36] So I think the best way to show is just to show you someone run mpm run test:coverage.
>> Brian Holt: And you can see here these all have pretty bad coverage this is why they're in red. Of all the files that you have imported into test, which keep in mind, I have a lot of other files that I haven't.
[00:01:00] This is just the ones that are being imported. Only 22% of them are covered by state or 22% of statements are covered by tests. That's really low. Anything under 80 is probably not sufficient. 7% of branches, 21% of functions, but I still did pass all my tests, right?
[00:01:21]
>> Speaker 2: What's a branch?
>> Brian Holt: A branch can be like you covered the if statement but you didn't cover the L statements. All right, so actually let's show you even a step further, if you hit ls now. You can see I have this coverage directory. You should ignore this first of all.
[00:01:39] This is generated by Istanbul. I'm going to go into coverage and it will give you a bunch of stats and stuff like that. You can feed this in through a JSon file, but the interesting one here is the lcov-report directory. So if you go into there, and I say open index.html, this is just going to open it in my default web browser.
[00:02:03] In my case, I'm in Mac so this works. This doesn't work in Linux and I don't think in PowerShell either. But just, whatever the case, open this index.html file in a browser and you'll get a nice generated report of this. And I can actually click in the details and I can see all this stuff you didn't cover with tests.
[00:02:24] You didn't cover the error case. You didn't render all this stuff. None of this works, right? So you can see here, this loading thing was covered, right? We did a good job of covering that, but we didn't cover the rest of this so that's why we get pretty bad code coverage.
[00:02:41] But that's interesting we didn't actually test Modal.js did we, right? We didn't write that, but if you remember, that's imported into the details page. So if I go into here as well,
>> Brian Holt: Notice this stuff is all ran once. You can see that by the 1 x right there.
[00:02:58] That's probably pretty hard to see. So you can see this was run once, but nothing inside of Modal was ever actually tested because our test and actually instantiate modal, did render Modal or do anything like that. So we have the guarantee that if I import Modal, it's not going to throw an error.
[00:03:20] But we're not assured of anything more than that.
>> Brian Holt: So this is really useful as well. Another cool part of jest and Istanbul in general.
>> Brian Holt: And the nice thing is I didn't have to set this up. If you've ever had to set up Istanbul by hand it's a pain.
[00:03:41] So it's really nice that jest just has this built into it. So before you like, I'm gonna do this, I'm gonna get 100% test coverage and it's gonna make me look great. I want you to warn you of the false god of test coverage. People think that if you have 100% test coverage, that means my repo is well-tested.
[00:04:04] Well, as you saw with Modal.js, I had 16% test coverage of Modal.js with a garbage test, right? It told me absolutely nothing other than this didn't throw an error. There's no syntax errors. That's about all I got from Modal.js. It's possible to have absolutely garbage test and 100% test coverage.
[00:04:24] So what you should use test coverage for is that I'm not covering less of my code with test, right? It's kind of a relative thing, so relatively to previously, I'm maintaining how much test I have, the goal is not a 100% test coverage, the goal is good tests, right?
[00:04:43] The goal is having, if I launch new code inter production, I'm not going to crash, right? That's what test is gonna help you do, and a 100% test covers doesn't mean that, okay? So I rather have 50% test coverage with great test, then a 100% test coverage with garbage test.