Webpack 2 Deep Dive Coverage Exclusions and Webpack Middleware

Transcript from the "Coverage Exclusions and Webpack Middleware" Lesson

[00:00:00]
>> [MUSIC]

[00:00:03]
>> Kent C Dodds: Yeah, let me just check out that branch. And then I'll remove that config and show you the problem with not including this. So now if I run npm run test or npm test or npm t. All of those are the same.
>> Kent C Dodds: And I'm going to get this handy dandy coverage summary right here.

[00:00:31] And this is the exciting part. So this is the text reporter, the text-summary. That's what I'm seeing right here is that text-summary. It also generates a JSON file and LCOV report. And as part of those reports inside of this coverage, there's an LCOV report directory that has all of the code coverage reports for my app.

[00:00:58] So if I open and it's an index HTML so we can open this in a browser. So open the lcov-report/index.html. That will give me this pretty almost web appy looking thing where I can look at code coverage. So this is cool, I can see what lines were covered.

[00:01:20] Looks like because we required the module, it ran this line one time. But because we're not actually calling any functions on it or anything, we're not getting any coverage here. For all these prototype assignments, we're covering those lines. So yeah, we have a lot of work to do on this file.

[00:01:39] But there's one problem here. And that is that it's including our controller test file as well and reporting code coverage for that. So anybody who wanna venture a guess why this would be a problem?
>> Speaker 2: You're not testing your tests. [INAUDIBLE]
>> Kent C Dodds: Yeah, it's like we're testing our tests, and making sure that our tests run.

[00:02:02] And we want them to run, right? It would actually be really interesting to know if our tests aren't running. If we're not covering all the lines of code in our tests, that would be like okay, yeah, probably delete that stuff. But what it's doing is it's inflating our code coverage statistic.

[00:02:19] Because if you look at this, this is 15%. And we have 0% of our branches and 16% of our lines. But we have 100% of our unit test. And so if we look at the summary, it's a lot better than 15% or 16% of lines. And so it's inflating our code coverage.

[00:02:39] And we can't really track the code coverage of our app very well. And so that's what the purpose of this little bit of configuration here is. And actually, yours truly added this feature to this library, copied it from a different one. So I can't really claim too much credit.

[00:02:58] But this is an important feature for any code coverage tool is the ability to not cover files that match a certain file extension. So all of our tests, and we also have potentially stub the files that would be related to our test as well that we don't want to include in our code coverage stats.

[00:03:20] So then if we run the test again, pop open our browser. And we get new code coverage summary that excludes the test.
>> Kent C Dodds: That all makes sense? Clear as mud, hopefully clear. Let me just make sure that I covered everything here. Feel free to interrupt me and ask questions.

[00:03:59]
>> Kent C Dodds: One other thing that I didn't mention earlier that I probably should have. Because you'll likely run into this when you're doing this yourself. Is this webpackMiddleware property that just magically appeared in our config. Yeah, I forgot to mention that. We'll take this out and I'll show you why this is important.

[00:04:17] If we run our tests again, we're going to get this webpack wait until bundle is finished. And then a whole bunch of output here that's saying all of the modules that it's loading. As your application grows, this is gonna get bigger and bigger and bigger. And it's gonna really inflate your output from your tests.

[00:04:36] And it makes it a lot more difficult to debug tests and stuff. So that's what the purpose of this webpackMiddleware is or that's why it's there. Is so that we just say, I don't care about that stuff, just show me the output for the test. If you needed to debug something like some module's not loading properly.

[00:04:53] Or something that you might use, something like that. But otherwise, it's not necessary. Cool, everybody having so much fun? [LAUGH] Okay, cool, so I don't see. Okay, there is one question from Henry. Why is it choosing only one file from the source directory? Good question, so the reason that it's only loading the controller.js file.

[00:05:25] And that's actually perfect segue, Henry. I'll pay you later. It's only loading this controller file because that's the only one that's required by our test. So to be a little bit more accurate, Karma is saying, okay, my files. I'm gonna go ahead and find all the files that match this glob, this pattern.

[00:05:46] There's only one. And so it says, okay, let me load that. But first, I'm gonna preprocess it with Webpack. And so I'll resolve this require. And so that loads in controller. Now controller doesn't match the exclusion pattern that we have for instrumentation so it instruments that. But it doesn't load any of the other files.

[00:06:04] Karma doesn't load it. Webpack is not gonna load it because we're not requiring it. And so that's why we only get controller.js instrumented is because it's the only one that's actually loaded into the browser and instrumented it all. So that's the next thing that we're gonna solve. Oscar is asking, how do you access the coverage webpage open coverage.

[00:06:26] So yeah, you could actually go into the coverage directory, directory lcov-report. And then right-click on the index.html or open it however you do. And I think I've gotta open a new window. No, that's not gonna do what I think it is. I always just do it from the command line.

[00:06:45] So it's open coverage/lcov-report/index.html, and that'll pop open my browser. But yeah, it's just a static file in your file system.
>> Kent C Dodds: Cool, so in ten minutes, I showed you what took me probably weeks and months of time to get working. But the tooling is so much better than it used to be, so good times.

[00:07:14] Yeah, so the next thing that we are gonna do is just like Henry was talking about. Is what we're getting here is coverage for the files that have coverage. But we're not getting a report on coverage for the files in our project. And that's what we really care about.

[00:07:32] We want to find out, okay, how many lines of code are not covered in our tests in our entire project? So that's the next step here.