JavaScript coverage with Istanbul and Coveralls via Travis CI

Components used: Mocha, Istanbul, Coveralls, Travis, node coveralls, make

Since then I’ve been looking for alternatives to using JS Coverage for doing coverage instrumentation. There are two main issues with it:

  • It’s C component that needs to be (sort of manually) installed
  • It requires you to implement a mechanism within your modules exports to be able to switch between the the instrumented code and the original code (usually done with a runtime variable i.e. PKG_COV=1)

The second issue is the bigger pain as I want the coverage component to do all that for me. After some digging around and experimentation I decided upon Istanbul as the component to use. Mainly because it’s written in pure JavaScript and it seamlessly integrates with your existing build.

Before starting it’s worth understanding a little bit about how it integrates with your code. It works by having hooks hooks into where your code includes it’s libs. The two hooks are:

  • require
  • vm.createScript

If your tests don’t include your lib files via this mechanism then the instrumentation won’t work. It’s therefore worth noting that your codebase must conform to CommonJS i.e. the lib files must do module.export = Lib or exports.Lib = Lib etc. I’m still looking for a way of doing the instrumentation when require is not used and if I find something I’ll write an update.

Getting it working

Key commands
  • istanbul cover _mocha -- -R spec test/spec – the key here is to note that _mocha is being used. This is due to the way that the process is being spawned see here
  • cat ./coverage/ | ./node_modules/coveralls/bin/coveralls.js – this takes the coverage report generated by the previous command and pushes it to coveralls

There are basically a few files you need to modify:

before_script: 'npm install -g istanbul && npm install -g mocha'
script: 'make test-cov'
after_success: 'make coveralls'

view raw


hosted with ❤ by GitHub

test-cov: istanbul
istanbul cover _mocha — -R spec test/spec
cat ./coverage/ | ./node_modules/coveralls/bin/coveralls.js

view raw


hosted with ❤ by GitHub

"devDependencies": {
"coveralls": "2.3.0"

view raw


hosted with ❤ by GitHub

  • I’m using mocha as a test framework but any other can be used.
  • I’m assuming you’re already familiar with travis and coveralls and haven’t covered any setup information here.
  • I’m using Make but it’s not required. The commands are the same though.

Tagged with: , , , , ,
Posted in git, github, JavaScript, nodejs, TDD

GitAll to mange your GitHub repositories

Do you work with multiple GitHub repositories over multiple user or organisation accounts? Ever wanted to clone or update all your GitHub repositories with one command? Then GitAll is the tool for you. You can get it from GitHub here.

GitAll is a tool to mange (clone, update etc) all the GitHub repositories for multiple user (or organisation) accounts in one command.

  • {action} can be [|clone|update|status|config]
  • {user} is the account name. This is case sensitive
  • {dir} this is the target dir, defaults to current dir ‘.’
  • {protocol} [ssh|https|svn] this is the protocol to be used to fetch the repo, defaults to ‘ssh’
  • clone – clones all repositories
  • update – updates all repositories
  • status – gives status for all repositories
  • config – gives the config in `$HOME/.gitall/config.json`

You setup the config for the accounts that you want to manage in a config file $HOME/.gitall/config.json.
Example config is:

   "username": "BoyCook",
   "dir": "/Users/boycook/code/boycook",
   "protocol": "ssh"
   "username": "TiddlySpace",
   "dir": "/Users/boycook/code/osmosoft/tiddlyspace",
   "protocol": "ssh"
How it works

GitAll works by either setting up config in the config file, or passing it parameters on the command line.
Parameters passed in will take precidence over parameters found in the config file.
It’s much better to setup the config in advance and let the GitAll do all the hard work.


gitall {action} {user} {dir} {protocol}
The final three are optional

Example usage with config file
gitall clone
gitall update
gitall status

These will perform the action specified on each account setup in the config file.

Example usage passing in parameters
gitall clone BoyCook /Users/boycook/code/boycook ssh

This will clone all the repositories for the user BoyCook ( into the directory boycook using
the ssh protocol.

Posted in cloning, git, github, nodejs, repositories

Integration testing node.js web apps with JavaScript

These are some loose guidelines for integration testing a web app in JavaScript. Ideal if you need to test an ExpressJS app or any kind of web service.

The key issue is being able to stop and start the service as part of the test harness. Two ways of doing this are:

Using Mocha

Mocha is really useful because it has before and after hooks that can be used. These run once at the beginning and end of the test run and can be used to stop/start the service like so:

var server;
before(function (done) {
   server = new HttpServer({port: 8080}).start(done);

after(function (done) {

The full code can be seen here:

var http = require('http');
var server = undefined;
function HttpServer(config) {
this.port = config.port;
HttpServer.prototype.start = function (fn) {
server = http.createServer(function (req, res) {
res.writeHead(200, {'Content-Type': 'application/json'});
res.end(JSON.stringify({ data: 'Some data'}));
}).listen(this.port, fn);
console.log('Server started at [%s]', this.port);
return this;
HttpServer.prototype.stop = function (fn) {
if (fn) {
exports.HttpServer = HttpServer;

view raw


hosted with ❤ by GitHub

var should = require('should');
var request = require('request');
var url = 'http://localhost:8080';
var HttpServer = require('./server').HttpServer;
var server;
describe('HttpServer', function () {
before(function (done) {
server = new HttpServer({port: 8080}).start(done);
after(function (done) {
it('should get root ok', function (done) {
request(url, function (error, response, body) {
body.should.eql({ data: 'Some data'});

view raw


hosted with ❤ by GitHub

Using a wrapper file

A wrapper file can be used that uses node.js spawn via require('child_process').spawn. This will spawn subprocess as if running a shell command. I have an example gist here:

var spawn = require('child_process').spawn;
var server = require('./server');
var spawns = {};
server.start({port: 8080}, function () {
createSpawn('jasmine-node', [ 'test/spec', '–junitreport', '–forceexit' ], logToConsole, logToConsole);
createSpawn('casperjs', [ 'test', 'test/ui' ], logToConsole, logToConsole);
function createSpawn(name, args, stdout, stderr) {
spawns[name] = true;
var spawned = spawn(name, args);
spawned.stdout.on('data', stdout);
spawned.stderr.on('data', stderr);
spawned.on('exit', function (code) {
spawns[name] = false;
// logs process stdout/stderr to the console
function logToFile(data) {
fs.appendFileSync(output, data, function (err) {
console.log('Error writing to file');
if (err) throw err;
function logToConsole(data) {
// Hack – Shutdown when all processes are done
function safeStop(code) {
var running = false;
for (var key in spawns) {
if (spawns[key] == true) {
running = true;
if (!running) {

view raw


hosted with ❤ by GitHub

Tagged with: , , ,
Posted in Uncategorized

Automated JavaScript testing with Mocha and js-coverage for NodeJS

I used to extensively use Jamine and Jasmine-Node for my JavaScript testing. While jasmine is great I’ve recently moved over to Mocha for several reasons but primarily because it supports coverage reporting.

Here are some basic steps to get going. There are several key components required, click on the different links and follow the installation instructions:

Setting up coverage

Tests must be configured to run with the instrumented code so that coverage works. The coverage command creates the instrumented version of the code in the lib-cov directory:

jscoverage lib lib-cov

The tests need to use these files instead. When using RequireJS (or node.js) this can be done by modifying index.js and using an environment variable. Calling the environment variable APP_COVERAGE (which you would have to set before calling the tests) it would look something like this:

module.exports = process.env.APP_COVERAGE ? require('./lib-cov/app') : require('./lib/app');

If there are multiple modules in a directory you can do something like this:

var module1 = process.env.APP_COVERAGE ? require('./lib-cov/module1'): require('./lib/module1');
var module2 = process.env.APP_COVERAGE ? require('./lib-cov/module2'): require('./lib/module2');

module.exports = {
   module1: module1,
   module2: module2

Then in the tests you can just require the modules as appropriate:

var app = require('../../index.js');


var module1 = require('../../index.js').module1;

Using Makefile

I have a standard Makefile that I use for running builds

TESTS = test/spec
XML_FILE = reports/TEST-all.xml
HTML_FILE = reports/coverage.html
test: test-mocha
$(MAKE) test-mocha REPORTER=xUnit > $(XML_FILE)
test-all: clean test-ci test-cov
@NODE_ENV=test mocha \
–timeout 200 \
–reporter $(REPORTER) \
test-cov: lib-cov
@APP_COVERAGE=1 $(MAKE) test-mocha REPORTER=html-cov > $(HTML_FILE)
jscoverage lib lib-cov
rm -f reports/*
rm -fr lib-cov

view raw


hosted with ❤ by GitHub

Here’s a breakdown of the tasks/rules:

  • make test runs the tests and displays the results in the terminal. This is perfect for developer use
  • make test-ci runs the tests and creates an xUnit format XML report
  • make test-cov runs the tests and creates coverage report HTML file
  • make test-all runs the test-ci and test-cov tasks creates both the xUnit format XML report and the HTML coverage report. This is perfect for CI use

Showing coverage in Jenkins

If you have installed the Jenkins HTML Publisher Plugin and are using the make test-all command, you can then configure Jenkins to use the generated HTML coverage report by adding the “Publish HTML reports” post build action and configuring it to use the coverage.html file.

Live example

You can see an example of a fully working project in my HttpFileServerJS project (please note that this is subject to outages):

HttpFileServerJS GitHub project

HttpFileServerJS Jenkins job

Tagged with:
Posted in JavaScript, nodejs, programming, TDD, testing

Node.js configuration for session with redis edit

var RedisStore = require('connect-redis')(express);
app.use(express.session({ secret:'appsecret', store:new RedisStore, cookie:{ maxAge:60000, expires: false } }));
Posted in Uncategorized

XML find and change node script

This is a script written in ruby designed to find a specified node in an XML file, and replace one value with another.

Usage example:
changenode /home/me/foo bar.xml name bob john will find all ‘name’ nodes in bar.xml and replace ‘bob’ with ‘john’

The code can be found on github here

Tagged with: , , ,
Posted in programming, scripts

JavaScript Map object implementation

The idea of this object is to mimic the API of the Map object in Java.

It can be used in the following way:

var myMap = new Map();
myMap.put('foo', 'bar');
var bar = myMap.get('foo');

I know this behaviour can also be attained by using an array in the following manner:

var myMap = [];
myMap['foo'] = 'bar';
var bar = myMap['foo'];

But I thought it interesting to implement it as a map too.

The code can be found on github here

Tagged with: ,
Posted in programming

Replace webapp in deployed tomcat

This script will quickly replace the webapp dir of a deployed webapp in tomcat. It scans at your current directory tree for an appropriate artifact.
It will look for a target subdirectory, and will try to find a .war file in it (assumes you’ve build your app with maven).

The script takes two parameters, ‘webapp’ and ‘dir’:

  • The first is the name of the webapp deployed in tomcat
  • The second is the dir to move into the deployed webapp

Usage examples:
ctw myapp mydir will copy mydir into the myapp webapp sitting in tomcat

NB: all parameters are case insensitive
The script can be found on github here

Tagged with: , , ,
Posted in programming, scripts

Copy to apache script

This script is designed to work with OS X and will copy the specified dir into the users local sites dir.
It looks for the specified dir, and if it exists copies it into apache. If the dir already exists in apache, it first deletes it.
The script takes one parameter, ‘dir’ which is the dir name.

Usage examples:
ca mywebapp copies dir mywebapp into $HOME/sites/mywebapp

NB: all parameters are case insensitive
The script can be found on github here

Posted in programming, scripts

Copy to tomcat script

This script will quickly copy an app into tomcat by scanning at your current directory tree for an appropriate artifact.
It will look for a target subdirectory, and will try to find a .war file in it (assumes you’ve build your app with maven).

The script takes two parameters, ‘tomcat’ and ‘app’:

  • The first is asking whether to start/stop tomcat, it takes ‘Y’ or ‘N’ as options
  • The second is asking what to copy to tomcat. It has the options of ‘W’ or ‘C’. ‘W’ means copy the whole war, ‘C’ means copy just the compiled classes

Usage examples:
ct y c will stop/start tomcat and copies just compiled classes
ct n w will not stop/start tomcat and copies the war

NB: all parameters are case insensitive
This script requires the Generic tomcat script found on github here
The script can be found on github here

Posted in programming, scripts
%d bloggers like this: