Check out a free preview of the full Intermediate React, v5 course

The "Testing Coverage" Lesson is part of the full, Intermediate React, v5 course featured in this preview video. Here's what you'd learn in this lesson:

Brian demonstrates how to generate a test coverage report. The report summarizes the percentage of statements, functions, and lines of code covered by a test. A web interface is also generated inside the src/coverage directory which allows developers to click on source files and view which lines are not covered.

Preview
Close

Transcript from the "Testing Coverage" Lesson

[00:00:00]
>> Let's go do coverage now that we've been talking about it. I think it's interesting to look at coverage, it's also cheap now to look at coverage. It used to be hard to set up Istanbul, it's now very easy to set it up so I think it's useful for you to look at but don't let it be gospel.

[00:00:16]
That's why I don't like companies to say, we maintain 70% test coverage, silly. It's a silly number to try and chase, right? But it is useful to look at the report and see like, okay, here's a bunch of things that I find very important about my app that are not being covered.

[00:00:33]
That is very useful information for you to have. So let's go ahead and set that up. We're gonna go back to our package.json momentarily. We're gonna add another script here under vi test called test:coverage. And I'll use vitest--coverage I believe. Yes, yes, yes. If you can spell, that was was a rough go of trying to spell coverage.

[00:01:04]
All right, there we go, coverage. Here we go. So stop this and then I want you to run mpm run test:coverage. It's going to ask you, do you wanna install something? And just say, yes. Just like that, do you want to install the test coverage-c8? The answer is yes.

[00:01:29]
Okay, it's gonna give me this really nice little output here of like, here's all of the files that you are covering with your tests. Here's how many percentage of statements that you're covering. How many branches? How many functions? How many lines? In this particular you can see that in catch by.

[00:01:50]
What is this? Use breed list.
>> Fetch.
>> Fetch breed list, thank you. Lines 11 through 13 are not covered. So fetch breed list here 11 through 13. We don't cover that this error gets thrown correctly, right? Probably okay. So that's pretty cool but if you go here and there is a coverage source/coverage.

[00:02:17]
And I think there's an index.html in here, yeah? So open that in your browser. This will actually give you a nice interface. So I can actually go in here and click in this and I can see, okay, this is what's not covered, right? This was covered one time.

[00:02:35]
This was covered two times. If we go back and look at something like carousel, you can see this line was hit 20 times. That's what those Xs mean, how many times these were hit. So on and so forth. So you can see all of these files are covered.

[00:02:55]
It's giving me a really rosy result right now but it's not showing me all the files in my project that are not covered, right? So you can see here for example, modal.jsx is totally just omitted here cuz I don't have any tests for it. But of the things that I have written tests for I have 98% test coverage from my statements, right?

[00:03:12]
And a 100% function coverage and so on and so forth. So if you've ever used Istanbul or NYC which are relatively the same thing for the most part, this should look familiar, this is called an L-curve report, LCOV. I do not know what it stands for. This is actually being generated by a different test coverage tool called c8.

[00:03:39]
I would suggest now if you're on Istanbul or NYC to just move to c8. C8 is actually the built in test coverage tool to Node.js so it's actually built into node. It's much faster than Istanbul. Istanbul is single threaded and sequential is very slow. They made NYC which then became multi-threaded or at least could be run in parallel is maybe a better way of putting that.

[00:04:05]
And then now there is c8 which is actually built directly into Node.js which is way faster cuz it's in C or C++ or something like that. But you can see here it's compatible with test reporters for Istanbul. So the rest of your pilot pipeline will look exactly the same.

[00:04:27]
Okay, make sense? Any questions about that? Like I said, this is a very useful thing. For me let's say I had like. I don't know, got looking here at fetch me this. Let's say that this era was very important. I could go in here and look at my test coverage and say like, hey, this is critical functionality.

[00:04:49]
Now I know I need to write another test to cover this piece of functionality that lets me know, am I covering the things that I find important about my app?

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now