JS Code Coverage 101

JS Cover 101 - JavaScript Code Coverage for dummies

This is part one of a series of posts in which I’m covering the basics when it comes to setting up code coverage for JavaScript. There are a lot of intimidating manuals, guides and confusing blogposts out there, but don’t worry! We will walk through all basics from installation to automation.

JS Code Coverage – Introduction

Within the first part of this series we will setup JSCover and configure a simple environment in which manual code coverage tests can be executed. The tests are based on basic sample pages, however, you can replace this with pages from your website.

Later in this series, we will cover more advanced topics and tools like selenium, unit tests and jasmine.


I’m using a Windows configuration with IIS responsible for serving the website, however the samples aren’t depending on a specific configuration or programming language.


Step 1 – Install The Java Runtime Environment

We will be using JSCover (http://tntim96.github.io/JSCover/) as our JavaScript code coverage tool and therefore need to be sure that the Java Runtime Environment has been installed. As this is one of the prerequisites.

I’m using JRE version 8 Update 91, which can be found right here: https://java.com/en/download/manual.jsp

Note: Don’t worry about Environment Path issues, this will be covered later.

Step 2 – Download JSCover

The latest version of JSCover can be found right here https://sourceforge.net/projects/jscover/files/ Unzip the files to c:\tools\ JSCover-1.0.24\ or any location of choice.

Step 3 – Copy sample data

Within this step we need to copy some assets, allowing us to measure code coverage. To keep things simple, I’ve decided to use the sample data included with JSCover.

The sample files I’m using can be found within the folder JSCover-{your version}\doc\example. Copy both index.html & script.js to the root directory of your test website. The index will be accessed later using a Url like: http://localhost/index.html.

It’s important to know that these files have not been instrumented (altered for testing purposes) and similar to any other website resources.

Running Tests

JSCover supports several ways of measure code coverage. Probably the most recommended method is called File Mode and involves pre-instrumenting your .js files on the file-system, and have the server serve up the instrumented code. Fortunately, this process can be performed by calling a simple command.

Step 1 – Generating Instrumentation

The command below can be used add instrumentation to your code and consists out of the following parts:

"C:\Program Files\Java\jre1.8.0_91\bin\java.exe" -jar target\dist\JSCover-all.jar -fs C:\inetpub\wwwroot\mysite C:\inetpub\wwwroot\mysite _instrumented

..java.exeThe first part points to your java installation which might be different depending on your JRE version, operating system and environment path.
JSCover-all.jar is the java package file which contains JSCover logic.
-fs represents the File Mode which tells JSCover to generate instrumentation.
C:\inetpub\wwwroot\mysite is pointing to the location where files need to be instrumented. (index.html and script.js should be present at this location)
C:\inetpub\wwwroot\mysite _instrumentedis the location where an instrumented copy of your website will be created.

To execute the command, simply open a command or PowerShell prompt (Run as Admin), navigate to your JSCover folder and make sure to alter the statement so it matches with your environment.

Note:The root of the instrumented website also contains some additional files which we will use when executing manual tests.

Note: Additional details can be found within the documentation: http://tntim96.github.io/JSCover/manual/manual.xml#fileMode

Step 2 – Serving Instrumented code

After executing the command, we need to make sure the webserver is serving the instrumented code instead. I’m just renaming mysite to backup and mysite _instrumented to mysite just to keep things simple.

Feel free to host the instrumented version within a separate website, just make sure the underlying file permissions are matching.

Step 3 – Manual tests

Open the following Url within you instrumented website using a browser of your choice http://{your-location}/jscoverage.html. A screen similar as the image below should be visible (I’m using port 8000, don’t let this confuse you):

JS Cover GUI

Within the URL field open (open in frame) the location http://{your-location}/index.html. This is the test file we copied earlier and also located within the instrumented environment. You should see a page as included within this image.

JS Cover GUI manual test

Note: “Open in window” can be used if your website is having issues when loaded within an iframe.

When clicking on the Summary tab, you will see a result of the code coverage tests so far. Now go back to the Browser tab and interact with the test form. When done, open the Summary tab again and click on /script.js. This will open a view which visually represent the code coverage including the execution count of this file.

JS Cover GUI results

JS Cover GUI Details


Just some quick tips when working with your own website assets; Make sure that the output of your build process does not minify the .js files. This not only applies for your custom JavaScript files, but also any library you are using. Doing so will allow you to evaluate if it’s worth using a library when only a small portion is actually used.

In addition, the code execution count indicator is very useful. You might spot incorrect application behavior based on code execution count as I did in many cases.


As you can see, JSCover is really useful even when just running manual tests and not included any automation. Please note that adding instrumentation can be included very easily as a task within Grunt and there are several instrumentation plugins available for Gulp as well. This and more will be covered within an upcoming post.

  • Kaushlendra Chauhan

    Hi Kevin,
    Is there a way to store/save the report with the filesystem mode? I did not find any.
    Also, can this be tested by multiple users simultaneously and the coverage displays a consolidated report? Something like a single merged report for all users hitting my instrumented-code-application?

Post Navigation