- [Instructor] By measuring code coverage
we can find gaps in our test cases.
How do we do that?
Jest includes a code coverage tool
named Istanbul within it.
Istanbul separate open source project
but it's already included with your Jest installation.
What does it do?
Istanbul from Istanbul.js.org
watches your code execution in order to track
how well your unit tests exercise the code base.
This means if code is used
Istanbul We'll keep track of it and report it.
Istanbul command line interface is NYC.
Yes, the naming is confusing
as it reflects the merging of two projects
and is a subtle reference
to an old They Might Be Giant song.
in addition to supporting Jest
Istanbul supports other test frameworks
such as Mocha, AVA, and others.
Istanbul includes a number of different reporters
which format the results.
By default just uses them all.
The first is text,
which was that short report I demonstrated.
Another reporter is HTML,
which was the more detailed line-by-line report
I also earlier.
A third is LCOV which is a standard
for recording code coverage.
It was initially designed
for the Linux kernel source code,
but it supports any arbitrary project as well.
LCOV is most commonly used by third party tools
so they can operate on the output
and not worry about the API.
The last is Clover, which is an older code coverage product
open source by Atlassian in 2017,
which as of this writing seems to be no longer maintained.
Since Istanbul is already included in Jest,
we don't need to install anything in order to use it.
Instead, we'll configure the test script
in packaged dot Jason to include a test coverage report,
which is off by default.
Let's switch over to VS code.
Open up the terminal.
I'm going to maximize the screen by clicking the up arrow.
Let's check out the documentation before we begin.
Type MPX space, Jest, space, dash, dash, help
and press enter.
Scroll up, we're looking for dash, dash coverage.
That's a flag that indicates that tests coverage information
should be collected and reported in the output.
Sounds pretty straightforward.
In order to see this coverage every time
let's update the test script.
So we can remove the maximisation
and then open up package dot Jason.
Under scripts, edit test
to be just space, dash, dash, coverage,
save the change, then switch back to the terminal.
Scroll down, and then let's see our new test output.
Type MPM, space, test and press enter.
The tests pass and underneath is a code coverage report
generated by Istanbul, we're at 96% on statements
and lines which is quite respectable.
When we ran tests with coverage,
it created a directory called coverage,
which contains the generated reports.
From the Explorer, open coverage
within this directory are some generated files
and a sub-directory called LCOV report.
Let's open it now.
There's an index dot HTML file, this is the HTML report.
Right click on the file and go to reveal in file Explorer
or open containing folder
or whatever your local equivalent is.
Then right click on index dot HTML
and open with your favorite browser.
The report starts with all files in the project
and shows the coverage by directory.
Click on the name to navigate in such as Nadia lib.
Let's take a closer look at reservations dot JS
by clicking on it.
This is a line by line breakdown of the coverage.
If you hover your mouse over one of the red areas
the reason will appear as a tool tip
such as this unexecuted function.
Feel free to browse around.
When you're done click on all files.
Our library files are here
but what about the routes, app dot JS?
This isn't everything because we've only been testing
a portion of the code base.
Close the browser
and switch back to visual studio code.
Want a more convenient way of seeing code coverage?
Over on the left in the activity bar, click extensions.
Search for coverage gutters by Ryan Luker,
click install.
In the activity bar, click the Explorer again.
Then open lib reservations dot JS.
open the command pallet by typing control, shift, and P
type watch and select coverage gutters watch.
On the left I can now see green indicators for covered lines
and red indicators for uncovered lines.
It's not as granular as the full report
but it's a great start.
Let's clean up, let's close the terminal
and any open files.
If we functionally tested the application
we'd be executing things like routes,
which wouldn't benefit from a unit test.
Can functional testing be included in this report?