At the Forge - Testing JavaScript

In mid-November 2009, at a meeting of my research group in Chicago, I proudly unveiled the most recent beta of the software I'm writing for my PhD dissertation, a Web application (written in Ruby on Rails) that promotes collaboration among students and scientists. I was pretty confident the testing would not reveal too many technical problems, in part because I had used Cucumber and rcov to ensure a high degree of test coverage. True, my application uses some AJAX, which means there are certain things Cucumber cannot test. But, given how localized such functions are, and the fact that I used and tested them myself on a day-to-day basis, how much did it matter?

The good news is that for the most part, the beta test went quite well. There were a few problems to fix, and I started to come up with a plan to get to them. What bothered me most was not that bugs existed, but rather that the bugs were all related to JavaScript and AJAX. In other words, the high level of test coverage that I had achieved was good, but it was not sufficient, because it looked only at my Ruby code and not at the equally important JavaScript code in my application.

This was not the first time I had encountered issues with JavaScript testing. A project I worked on through much of 2009 used a great deal of JavaScript, and we tried to test it in a number of ways, none of which were particularly satisfactory.

So, I was pleasantly surprised to discover I'm not the only Web developer who has been trying to improve test coverage for Web applications that include a great deal of JavaScript. Indeed, currently a number of frameworks and libraries are available for JavaScript testing—some of which are specific to a particular JavaScript framework, some of which are plugins for Ruby on Rails (or other Web application frameworks) and still others that are fairly flexible and agnostic.

This month, I look at Screw.Unit, a framework for JavaScript testing I have begun to use in my own work. Even if you don't use Screw.Unit specifically, modern Web developers constantly must consider ways to write testable code, not only in their server-side language of choice, but also in JavaScript. JavaScript plays a central role in modern Web applications, and failing to test it thoroughly can lead to unforeseen problems, as I saw myself.

Screw.Unit originally was written by Nick Kallen (of Pivotal Labs) and distributed as open source on GitHub. A number of forked versions exist, and you might need to poke around to find one that is sufficiently mainstream and modern for your needs. I have been using Kallen's original version and rely on it for this article's examples. GitHub provides a number of methods for downloading software, but the easiest is just to “clone” the existing Git repository, with:

git clone git://github.com/nkallen/screw-unit.git

Inside the screw-unit directory, you will find a number of JavaScript libraries and CSS files, all of which are there to assist you when running JavaScript tests.

The basic idea of Screw.Unit is that you introduce a set of related tests with describe() and then each individual test with it(). The second parameter to it() is a function that invokes one or more assertions, using the defined expect() function.

Thus, let's assume you have a function defined that multiplies its parameter by 3:

function triple(i) {
    return i * 3;
}

You can test it in Screw.Unit with the following:

describe("Triple should triple", function() {
    it("returns 6 for 2", function() {
        expect(triple(2)).to(equal, 6);
    });
});

Notice the three separate levels of functions that are involved here:

In order to run these tests, you need to wrap the entire describe block inside an anonymous function, passed as the first parameter to Screw.Unit():

Screw.Unit(function() {
    describe("Triple should triple", function() {
        it("returns 6 for 2", function() {
          expect(triple(2)).to(equal, 6);
        });
    });
});

Finally, you need to pull in a bunch of JavaScript libraries that not only define Screw.Unit, but also the objects and functions on which it relies. The final version is shown in Listing 1, triple.html. Notice that while you are testing JavaScript, Screw.Unit assumes you are doing so within an HTML file. That allows you not only to load an (unfortunately long) list of JavaScript libraries, but also the CSS file that is used within Screw.Unit to display test results.