Enter Your Email Address to Watch This Lesson

Your link to unlock this lesson will be sent to this email address.

Unlock this lesson and all 986 of the free egghead.io lessons, plus get JavaScript content delivered directly to your inbox!



Existing egghead members will not see this. Sign in.

Adding code coverage checking

3:24 JavaScript lesson by

Now that we have code coverage being reported, let's make sure that nobody commits code which drops code coverage below our standard by adding a check-coverage script that utilizes istanbul's built-in check-coverage command.

Get the Code Now
click to level up

egghead.io comment guidelines

Avatar
egghead.io

Now that we have code coverage being reported, let's make sure that nobody commits code which drops code coverage below our standard by adding a check-coverage script that utilizes istanbul's built-in check-coverage command.

Avatar
David

Definitely like this topic, and it may be WAY out of scope for this, but 100% coverage is really REALLY difficult. Might be best to drop that to realistic expectations, but I don't know what "real world" should be. I've worked on legacy/inherited apps for years, so I'm not the best to provide information on this one.

In reply to egghead.io
Avatar
Kent C.

I agree with you for apps, but for libraries, getting 100% code coverage is not only possible, but I recommend it and do it for most of my more recent libraries. The difference is that the codebase is much smaller, and you're also exposing an API which should be what you're testing. If you can't get to all of your lines of code through just using the API the way a user of your library would, then do you really need that code?

Code coverage isn't the answer to all of our questions, but it certainly helps make sure that you're not shipping code that simply wont run :-)

In reply to David
Avatar
janppires

Hi Kent!

How can we integrate this coverage checking with webpack?

I have been searching but I haven't found anything. =(

Thanks!

Avatar
janppires

I got the answer myself.

In an webpack usage, we still need to install "istanbul" dependency, just to run the command "istanbul check-coverage build/reports/web-coverage/coverage-final.json --statements 100 --branches 100 --functions 100 --lines 100" agains the "coverage-final.json" produced by karma-coverage.
So it's important to have reporter type as "json" in the reporters array of coverageReporter karma.config file.

coverageReporter : {
          dir: 'build/reports/web-coverage',
          reporters: [
              {type: 'json', subdir: '.'},
          ]
      },

Cheers

In reply to janppires

Now that we have coverage reporting, we want to make sure that our coverage doesn't drop below a certain level. If we run NPM run test single, that we get our coverage reporting. We'll see that we have 100 percent coverage on statements, branches, functions, and lines. That's awesome, and it's actually quite easy to accomplish in such a small library.

In bigger libraries or in projects, it's a little bit more difficult to get that kind of coverage, and so having a standard that you can't drop below is a really good thing. As we add features to our Star Wars named library, we're going to want to make sure that we don't drop in coverage, but that we always test the new features that come in.

Let's go ahead and add a git hook using the g-hooks that we installed earlier for our pre-commit to make sure that we don't drop in coverage. We're going to add a new script, and I'll just enter it in here now. NPM run check coverage. Then let's go ahead and go to our scripts, and we'll add a check coverage script. This one will simply be Istanbul check coverage. This is where we'll specify what levels our coverage should be at.

For statements, we want it to be 100 percent. For branches, we want 100 percent. For functions, we want 100 percent, and for lines, we want 100 percent. Now if we run NPM run check coverage, then it will succeed if there's nothing wrong with our coverage.

Let's go ahead and drop our coverage a little bit. If I add a random function in here, do something, and we considered out, log hi, our tests aren't running this, our codes aren't running this, this function won't be covered.

Now if I run NPM run test single to get our coverage reporting, you'll see that our functions are down to 50 percent. Now if we run NPM run check coverage, we're going to get a big error. It will explain that our coverage isn't to the standard that we specified.

This is part of our pre-commit git hook, we won't be able to commit to our code anything that drops below our coverage standard. Which in our case with this small library is 100 percent across the board, that is how you add coverage checking to your library.

Because we have this now, we want to actually add this to our Travis, that not only will the test run, but we make sure that we have everything covered before we release any new version. We'll have NPM run check coverage and that will be part of our Travis build.

In review, all that we need to do is we create a script called check coverage. We use Istanbul's built-in check coverage functionality, and we specify our standard for statements, branches, functions, and lines.

Then we also added the check coverage command to our pre-commit git hooks, nobody can commit coverage that is below our standard. In the case that something ever does happen, we have this in our Travis as well to make sure that we don't really send anything that is below our coverage standard. That's how you add coverage checking to your library.

HEY, QUICK QUESTION!
Joel's Head
Why are we asking?