Update as of April 7, 2013: This blog series has now been extended with Jasmine and Istanbul.
Update as of March 28, 2013: This blog series has now been upgraded to use Grunt-0.4.

A lot of projects use continuous integration these days. It is still far more common for back-end projects using C#, Java or Ruby than it is for JavaScript projects. But front-end projects using JavaScript can also benefit from continuous integration, and this series of blog posts will show you how easy it is to set up using available open source tools.

I will show how to do fully automated code quality analysis with JSHint, unit testing with QUnit, code coverage with JSCoverage and continuous integration with Travis-CI.

Continuous integration means that your code will be checked automatically on every commit. If you commit often, you will get very precise information about what change introduced an error. Frequent and precise feedback is the cheapest way to keep bugs at bay.

All continuous integration systems rely on the ability to do the checking of the code from the command line. This blog post is about front-end JavaScript. While it is meant to be run in a browser, nonetheless there are great tools available for checking this front-end JavaScript code from the command line. Here I will focus on Node and Grunt. You can access the sample code in these blog posts at GitHub.

You will need only a single tool being installed globally on your system, namely Node. All other tools will be added locally to your project directory.

First step is to install Node on your system. Follow the instructions.

Your first goal will be to check your JavaScript code quality using JSHint, a tool that detects errors and potential problems in JavaScript code and enforces coding conventions. To be able to check the code from the command line we will use Grunt, a command line build tool for JavaScript. Grunt has built-in support for JSHint.

You can use the Node Package Manager, npm, to install any other tools you will be using. Npm is configured using a file called package.json located in the root directory of your project. To let Node know that you want to use Grunt, you will need to add Grunt as a development dependency to package.json. I have included some standard Grunt plugins, that we will need later on:

  "name": "jsdevenv",
  "version": "0.1.1-1",
  "description": "A sample build environment for JavaScript",
  "author": "Lars Thorup ",
  "devDependencies": {
    "grunt-cli": "0.1.6",
    "grunt": "0.4.0",
    "grunt-contrib-jshint": "~0.1.1",
    "grunt-contrib-qunit": "~0.1.1",
    "grunt-qunit-junit": "~0.1.0",
    "grunt-contrib-watch": "~0.2.0",
    "grunt-qunit-cov": "~0.3.2"

You can then install Grunt locally by running the following command in the root directory of your project (the directory with package.json):

  npm install

Next thing to do is to configure Grunt to check your code quality. Grunt needs a configuration file, and we will use Gruntfile.js. A basic Gruntfile.js that will check your code quality looks like this:

/*global module*/
module.exports = function (grunt) {
  'use strict';

  var gruntConfig = {};
  gruntConfig.jshint = {
      options: { bitwise: true, camelcase: true, curly: true, eqeqeq: true, forin: true, immed: true,
          indent: 4, latedef: true, newcap: true, noarg: true, noempty: true, nonew: true, plusplus: true,
          quotmark: true, regexp: true, undef: true, unused: true, strict: true, trailing: true,
          maxparams: 3, maxdepth: 2, maxstatements: 50},
      all: [


Based on your style preferences you might want to configure JSHint differently than the example used here.

Note that Gruntfile.js is a JavaScript file, so it makes sense to include this file in the list of files to be checked. You may also need to tweak the second path of the array gruntConfig.jshint.all if your JavaScript files are located somewhere else in the project.

Now you can check the quality of your JavaScript code from the command line by running:

  grunt jshint

Next step would be to configure your continuous integration server to execute the following two steps on every commit to your project:

  npm install
  grunt lint

How to do this will depend on what continuous integration software you are using. In the next blog post I will show how to continuously integrate your JavaScript code with Travis-CI.

This post is part of a series on Continuous Integration for front-end JavaScript, read the other posts in the series:

3 comments on “Automated build for your front-end JavaScript code

  • This is great info, I am going to play around with it.

    Do you have a strategy for testing HTML? Or do you avoid that altogether and just test viewmodels or something similar?

    Also, being spoiled with NCrunch I now feel that testing that gives me anything but immediate feedback is tedious and very old fashioned to work with. Is the grunt watching feature of your other article the best we can do here, you think?


  • For another project I am using Backbone where a View will populate a Template. On one hand I can unit test the view with a mock template to assert what expectations the view have about the template, see an example here:
    On the other hand I can unit test the actual template to assert that the expectation the view have about the template is satisfied, see an example here:

    And then I can do actual end-to-end UI testing, but since they will be slow and brittle I only want a few of those for smoke testing purposes.

    And yes: A JSCrunch plugin for WebStorm would be absolutely awesome!

  • Excellent article with some very useful information, especially so with the inclusion of the Grunt watch utility.

    On the topic of end-to-end UI testing, one direction I have been experimenting with as of late is using a framework like QUnit, and writing unit tests that are actually closer to functional tests by emulating user interaction via JavaScript events. This is similar as far as the end goal to UI testing through tools such as Selenium, but allows the developer/tester to have full control over the UI through which it is testing. With that, I have the ability to mock any AJAX requests during test execution time, fire any DOM events, and do any sort of DOM inspection that I want, through JavaScript. I’m currently trying out this strategy with a feature that requires a user to be able to draw elements in SVG/Canvas/VML (dependent on browser support), and thus far as proven to be pretty quick and very stable.

Leave a Reply

Your email address will not be published. Required fields are marked *