If you’re only instrumenting the files in your project that are under test then your code coverage report will be misleading and it will be difficult for you to track or enforce improvements to application coverage over time. In this lesson we’ll learn how to ensure all source files are included in coverage reports and how to enforce a specific threshold so you can work toward improving application code coverage.
If we look at our code coverage numbers right now, it's actually a little bit misleading. Right now we're looking at about 25 percent of our statements in our project being covered, but that's not entirely the case.
If we look at the report in the browser, we see that only controller.js is being covered. But in the project we have a bunch of files that should have code coverage reported on them. In this lesson, we're going to make sure that those files are also instrumented for coverage.
To do this, we need to load all of the files that we want instrumented into the browser so that they're instrumented for coverage and Karma gets that report.
Right now we have this fileglob that's matching all of our test files. Only the test files are loaded and then Webpack resolves the requires and so we get the source files from that. But we're going to have all of those source files loaded into the browser.
Here we're going to actually change fileglob to be testglob, because that's truly what it is. We'll copy that and create a new glob called sourceglob. This one we'll modify slightly to have anything that does not include test or stub.
We'll add the sourceglob to our list of files and then we'll add another item in our pre-processors here for sourceglob. We're still going to be pre-processing those with Webpack.
If we run our tests, you see before we had 26 percent on our statements. After these changes we only have 23 percent on our statements. If we refresh our coverage report, we'll see that we have all the files in here that we want instrumented for coverage, not just the ones that have unit tests for them already.
This gives us a much better idea of what the coverage for our entire project is and it gives us something to work toward. The one last thing that we're going to do if we're going to be working toward a higher number in our code coverage is we don't ever want our code coverage in our project to go down.
We're going to add a check to make sure that our code coverage never goes down. To do this, we're going to install as a dev dependency Istanbul. The coverage report that we're generating with Karma is compatible with Istanbul and Istanbul has a CLI that will allow us to check that the coverage meets a certain threshold.
If we go to our scripts here, we'll add a check coverage script and this is where we're going to use the Istanbul CLI. We'll use the check coverage command. Here we're going to add a threshold for the four aspects of our coverage. If we scroll up here, we have our statements, branches, functions, and lines.
For our statements, we want 23 percent. We don't want to drop below that number. For branches, it's going to be five percent. For functions it'll be 9 percent, and for lines it'll be 24 percent.
If we run MPM, run check coverage, we'll see this output and the script passes. There's no error I'll put at all, but if we were to bump one of these up to above our threshold of coverage currently, then we're going to get an error indicating that our coverage is below the threshold.
We can go ahead and add this check coverage to our validate script, so when people go to commit the pre-commit hook will run and they won't be able to commit anything that drops the coverage below the threshold. This will help us work toward a higher coverage percentage in our code base.
However, we can't run this in parallel with the test. This check coverage script has to run after the tests have run and the coverage report has been collected. But with MPM run all, we can add this serial flag here and we'll put check coverage right there.
If we run our validate script, we'll see that it runs validate Webpack in parallel, our linting, our testing, and then it runs our check coverage.
We see again that that is failing. Let's go ahead and lower that back down to where our threshold is right now. We'll rerun our validate script and everything will pass.
Let's review. To make sure that all of our code is instrumented for coverage so that we can get an accurate reporting on our entire code base, not just the code that's under test, we added this sourceglob that matches all the files that don't match test or stub in the filename.
We added that to our files here, and then we also added that to our pre-processors so that it will be pre-processed with Webpack. That was enough to get everything instrumented for coverage.
We also added Istanbul as a dependency and added a check coverage script that uses Istanbul's check coverage to make sure that we don't drop below our coverage threshold. As we work toward better coverage in our code base we can increase this threshold so we never drop below the threshold that we set.
That's how you enforce coverage in your entire application.