Code Coverage

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

[00:00:03]
>> Speaker 1: Moving right along to code coverage. So let's all go ahead and check out the next branch, and get rid of all of our own stuff and pull the new stuff.
>> Speaker 1: And we're gonna do code coverage. So I actually the three of you who were here yesterday and maybe some people online are going to hear the same thing again.

[00:00:30]
I'm gonna quickly explain code coverage, how code coverage works in JavaScript and why it's important. So like I said, code coverage with library is you should probably just do 100% code coverage. There's not really any reason not to. And so because normally it's pretty easy, the problems are really well defined and it'll save you from breaking stuff when you're making changes or somebody makes a pull request or something.

[00:00:59]
So what code coverage is, basically consists of four metrics. Lines, branches, functions, and now I cannot even remember. Does anybody know what the last one is? My brain tonight just decided to give up, statements. All that Code Coverage tells you is that this line ran, or this if statement was evaluated to true, or it evaluated to false and so the alternate ran.

[00:01:37]
Or this function was run. All of that pieces of information. It doesn't say like this function was run with this state, it doesn't say like that. This function was called with a boolean rather than an integer, whatever. It just tells you that at some point during the running of your test, that this line and this function and this branch was hit.

[00:01:59]
So the way that it accomplishes this is through what's called instrumentation. What it does is something similar to this. It creates a global variable called coverage and that's an object. And then this coverage variable will add properties to it, like it will actually just to make it a little bit easier.

[00:02:22]
It will add a bunch of properties to it that are hash or something. I am not a 100% sure what the keys even mean. But then they have a value of how many times a certain line or something was.
>> Speaker 1: Run. And then it will stick these all over the place.

[00:02:41]
Literally everywhere, each having their own key with ++ at every line, every statement, everything. If you have an if statement, then you'll have true, and then another one here, else, another one here. Functions are the same. You'll have something in here. I'm pretty sure like with ES6 and default parameters you have (foo = ('hi') and it'll use some JavaScript fanciness to detect whether or not that default was ever used.

[00:03:21]
In ternary operators it'll be like const v = b or 'hi' : 'yo'. And here it'll use that same kind of JavaScript fanciness to check that as well, and, again, each one of these will be unique where ever you are it's gonna be something different. So by the end of it, what you end up with is, well, some pretty garbage code, but it's able to.

[00:03:53]
Well, I totally blew everything away, but let me just reset.
>> Speaker 1: By the end of it, you have this global variable that contains all of the information that's needed to tell what lines were run and what lines weren't. And then your instrumenter will create a report out of that to show you these are the lines that you're missing.

[00:04:17]
It's pretty cool and pretty magical, that's actually the whole thing I was trying to convince you of. It's not magic at all, it's just JavaScript. But that's what we're going to do for our code to make sure that we're covering our code properly.