The full video and many others like it are all available as part of our Frontend Masters subscription.

Kent C Dodds

Kent C. Dodds works at PayPal as a full stack JavaScript engineer. He host JavaScript Air and co-hosts React30 podcasts. Kent is an Egghead.io instructor and Google Developer Expert.

Kent C Dodds

PayPal

Coverage thresholds allow developers to indicate amount of statements, branches, functions, and lines that should be covered in an application. In this exercise, Kent modifies the Karma config file to include these thresholds in the coverage reports. The solution to this exercise is on the FEM/02.4-cover-everything branch.
- http://slides.com/kentcdodds/webpack-deep-dive#/13/5

Get Unlimited Access Now

Kent C Dodds: With the covering all of the files, we need some way to tell karma to load all of the files, and then tell Webpack to instrument those for coverage as well. So, this actually is a little bit more on the boilerplate side to, yeah, I'm just going to give you a couple of globs that's you.

Yeah, okay, so, let me just ask really quick. So, this is why, or having this fileGlob in our files array right here, is what's instructing karma to load our test files. But we want to also instrument our source files, so could anybody tell me how I instruct karma to load source files, as well as my test files?

You can talk, it's okay.
Speaker 2: To get your source files.
Kent C Dodds: Yeah, I have source files and but we want to treat those a little bit differently from our test files, right? We don't want to have those, instrumental for coverage, we also don't, I don't want to load our test files twice.

And so, we're going to have a glob that matches just our source files. And this glob took me probably too long to to write, but I finally got it correct. So, I'm going to copy it. This is the wrong one. Just going to copy it from here, our source glob.

Kent C Dodds: So yeah, fun afternoon from yours truly. So, and I'm going to rename this one, just to make it a little bit more explicit what it is. And for both of these, I want them both loaded into the browser, but I also want them both pre-processed by Webpack. Because, well, oops.

First of all, some of them are like requiring CSS. And so, karma's going to be like, what the heck is that? And the fact that it's requiring anything, karma's going to have a hard time with. So, both of them need to be included into the browser, and both of them need to be pre-processed.

But by doing things this way, we're only loading our test files once, and we're only instrumenting our source files. And that instrumentation is happening because this ignore here. Does that make sense for everybody? Okay, sweet. So, if we run our mpm t here, let me open up the chat, if anybody online has questions, then we'll open up our coverage again.

Kent C Dodds: And now, in our source, we see something that's a lot more helpful and interesting. We see that our app file actually is pretty well covered. And that's because we're getting kind of a side effect by doing things the way that we are. If you recall in our Bootstrap function, as soon as this function loads, it's starting to do a bunch of side effects.

And that's generally not a great idea for your modules, most of the time, your model should not do anything at the root level. This makes them harder to test, and there, it's a side effect of just requiring or importing that module. You don't want to have those side effects.

What you do instead is you bundle up all that logic into a function, and you export that. And then it's a lot easier to test that. But for Bootstrap, that's a little bit of an exception, because we want to actually do something when the user loads the browser, right?

We need something to kick off the whole thing. And so, we start out with the Bootstrap that ultimately is calling this Bootstrap function, which is calling up on load. And that actually kind of explains why our up JS file has pretty good coverage, because this is being run.

I'm not entirely sure why these two lines aren't getting covered, my guess is they, there's an error, it's probably thrown right here. Somewhere down the tree that it's blowing everything up, and so, the execution doesn't continue. That's likely what's happening. And so, because we don't want to have these side effects, and we want to, like Bootstrap, we don't really care as much about the logic in this file.

We can exclude it with karma. But I'm going to skip over that bit, because I think that you kind of get the idea of what what we're trying to do. Yeah, there's one other thing that I'm just going to show you, and we'll move on, and that is, once you start tracking code coverage, you want to make sure that it doesn't drop below a certain threshold.

And so, we're getting fairly good coverage. And so, we don't want our coverage to drop below the threshold. We want people to continue to contribute tests to our project. And so, the coverageReporter allows you to specify a check object that you can set for global coverage for your whole project.

I want statements to not get below 11, and branches to not go below zero, and functions, zero. And lines 11, of course, functions and branches would never go below zero, that's impossible. So yeah, but from here on now, if somebody gets, actually, let me just show you an example of what it would look like, in a scenario where somebody adds more code and doesn't add any tests.

But I'm going to fabricate that scenario by reducing or increasing our threshold, so, if I say 31, and then we run an PMT, then we actually get it. Error, the script will fail, and so, you can put this is part of your validate scripture, or whatever you're using to do your building, and you can make sure that people don't submit poor requests that will reduce coverage.

So, and that, yeah. That is that. Any questions? Okay, sweet. So, and I'm waiting for questions online too. The next thing that we're going to totally skip over pretty much 100% is migrating from require statements to ES6 modules. If you want to learn about ES6 modules, there are still tickets for sale at Midwest JS, and I'm going to be giving a talk called more than you want to know about ES6 modules.

So you'll, yeah, it will be fun, and you can learn all that you would have learned doing this. And you work yourself, so we'll skip past that and jump into tree shaking. And now we're only a half hour behind schedule, yeah?
Speaker 2: One came in there about how do you ignore bender JS files?

Kent C Dodds: Yeah, it would be the same thing. So you would just add that to, actually, I should, I didn't actually show you what that looks like that exclusion. So, you have this exclude in here, and so, you could have it exclude anything in node modules. And yep, take care of that.

So, Emmanuel is asking, would file glob equals, well, Emanuel is asking if this would work? That would not work because it also matches tests. So, you don't want to load your test twice in the browser, then you're going to have twice as many times running. So that would not be a good thing.

So, but you do want to have separate globs for each of them, so that, for some reason now, I can't even remember why it's important to have separate globs. Okay, yeah, so, Oscar is asking where I am teaching ES6 modules? Here in town at Midwest JS, if you can't make it then, I actually, you can go to talks.kentcdodds.com, which will take you to my repo.

And if you are diligent, you can see the meetup talk that I actually did. There is a recording available. And so, if you want to see a recording of it.

Ready to take your code to the next level?

Intense courses with world-class teachers and unlimited access to our growing library of videos for the great price of $39 per month.

Get Unlimited Access Now