Extending the Mocha tests into Jenkins (or Hudson):

Posted by Elf Sternberg as programming, web development

In my previous post, I described a simple routine for using grunt, mocha, and zombie to unit test HTML and Javascript web applications, even those written with abstractions like Coffeescript, Less, or HAML, with a certain degree of verisimilitude. The key elements were (a) use grunt to build the various components, then (b) use grunt to install the finished product into a distribution directory, (c) run the grunt server to look at that distribution directory, and (d) use a mocha/zombie script to access the server and see if the application downloaded and ran as expected.

The next step is to make it work with Jenkins, a Continuous Integration server. Now, I tend to work with very small teams, but CI is still valuable because it allows me to run unit tests with every check-in. I’m not going to help you install Jenkins– there are plenty of guides for that– but I recommend that you install the xUnit test coverage plugin and the Git plugin. Create a new project, point it at your Git repository, and set up for polling the Git repository. If the repository and GIT are on the same machine, even a “check every minute for a new check-in” is very efficient.

If you refer to the previous post, you’ll see that the grunt set-up sends all Mocha output to a file called tmp/results.xml, using xUnit as the output format. I chose that explicitly so Jenkins could read it. For our purposes, Jenkins can’t just download the repository, it also has to build it and test it. In my Jenkins’ project directory, I create a new shell command, and here’s the script:

npm install;
source bin/activate;
grunt --no-color dev;
grunt --no-color server mocha

The first command installs all of the things I need locally. My current project uses zombie, grunt, mocha, requirejs, coffee-script, among other things, all of which must be installed before I proceed.

The second line, activate, calls this script:

export PATH

This temporarily gives me access to everything else in the bin directory, as well as the hidden node_modules/.bin directory where the command-line executables for things like coffee, mocha, r.js, and so forth can be found. This is a trick I borrowed from Python, and it works well.

The third line calls my “dev” task, which is just a shorthand for “build:haml build:template build:recess build:coffee install”, all of which are little build or copy tasks I’ve defined in my gruntfile.

The last line invokes the grunt server and calls the mocha test we defined previously.  If all goes well, Jenkins rewards us with a message that the test passed, and if we review the test we find:


Initialization.should load the home page (from Mocha Tests)

Which is extremely satisfying.

This is just a preliminary experiment. But it shows what can be done with a little glue and a little knowledge.

Comment Form

Subscribe to Feed



July 2012
« Jun   Aug »