This post 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 blog posts 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.
Environment
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.
Setup
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 to add instrumentation to your code and consists 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.exe | The 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 _instrumented | is the location where an instrumented copy of your website will be created. |
To execute the command, 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, make sure the underlying file permissions are matching.
Step 3 – Manual tests
Open the following Url within your instrumented website using a browser of your choice HTTP://{your-location}/jscoverage.html. A screen similar to the image below should be visible (I’m using port 8000, don’t let this confuse you):
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.
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 that visually represent the code coverage, including the execution count of this file.
Tips
Just some quick tips when working with your website assets; Make sure that the output of your build process does not minify the .js files. This not only applies to 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 used.
Besides, the code execution count indicator is handy. You might spot incorrect application behavior based on code execution count, as I did in many cases.
Conclusions
As you can see, JSCover is useful even when just running manual tests and not included any automation. Please note that adding instrumentation can be included very quickly as a task within Grunt, and there are several instrumentation plugins available for Gulp as well.
Recent Comments