Automating Jasmine Tests with Chutzpah

posted on 11/08/12 at 05:01:02 pm by Joel Ross

Last time, I wrote about how I could use Jasmine to validate the functionality of a page. While that's a good outcome, it's not maintainable to load each Jasmine test runner into the browser and verify that all of the tests pass. Our site has hundreds of pages, so if this is going to work, it clearly needs to be automated.

Enter PhantomJS. It's a tool that allows you to run JavaScript from the command line. PhantomJS isn't explicitly designed to automate unit tests - it actually has quite a few other uses, including screen captures and network monitoring. Getting it set up to run unit tests on it's own was a bit cumbersome. Luckily I found Chutzpah, which uses PhantomJS, but is specifically meant to be used for automating unit tests.

The first step toward automation was to get our tests running from the command line. It turns out to be quite simple, and we can use the same HTML test runner page we created for our unit of measure page from last time. The command line just requires that you pass it the HTML test runner page to chutzpah:

chutzpah.console.exe index.html

Running that command results in output that shows that the tests passed:


Now we've automated the testing of one page. That's nice, but not quite what we want, since I don't really want to have to run this command line each time for each page. Luckily, Chutzpah allows you to run multiple test files at once - but only if you run the console runner against the JavaScript spec files directly, rather than using the HTML test runner pages. This is actually a good thing, since now we don't have to create an HTML test page for each and every spec we create. So I guess it's time to figure out how that works.

Our spec file doesn't have to change that much to get this to work. Remember that the main thing our test runner HTML page did for us was relate specs to the JavaScript file it was testing. So we're going to have to figure out how to link them without using an HTML file. Chutzpah also helps us here. It supports adding comments at the top of the spec file to indicate which JavaScript files it should include:

   1: /// <reference path="jquery.js" />
   2: /// <reference path="jasmine.js" />
   3: /// <reference path="jasmine-html.js" />
   4: /// <reference path="jasmine-jquery.js" />
   5: /// <reference path="index.js" />

Again, I'm assuming all of the files are in the same directory for simplicity, but in reality, you'd probably organize your Javascript a bit better than that.

Now, we can rerun our chutzpah command, but this time, we'll pass in the test spec JavaScript file:

chutzpah.console.exe index.specs.js

Running that will result in the same output as the original command we ran, which is what we expect, but not quite what we want - we wanted to be able to run all of the specs at once. Simple enough. Instead of passing in a file name to the console runner, we can just pass in a folder, and it'll run all of the specs in that folder.

chutzpah.console.exe .\

For the test repo I set up, I have three test files in the folder, and you can see the results from each file, as well as a summary of all of the tests run.


This is what we wanted. Now we can run one command, and all of the tests we have are executed at once. Well, it's almost what we wanted. What we really want is to run these automatically whenever we check in code - so it runs on our continuous integration server.

As it turns out, this was the easiest part. We use Jenkins at TrackAbout, so I set up a Jenkins server locally, set it up to look at my GitHub repo, and then made a few changes to see what happens when a test fails. To get Chutzpah and Jenkins working together correctly, you just add a "/silent" parameter to the command. And what happens when a test fails? Sure enough, Chutzpah reports it and fails the build without any extra work on my part:


If you enlarge the image, you'll see that the build failed, and the log reports exactly which test failed in which file. Perfect.

As a result of the work over the past three posts, I now have a way to validate that the JavaScript code I write is working correctly, and have the running of those tests completely automated.

Discuss this post

Categories: Development