For some years now, I’ve been writing lots of JavaScript. Not that I chose to, but it is the only available language for client-side programming. Well, not really since there are some languages that will compile to JavaScript. So, I chose to work with CoffeeScript lately, since it is far better than JavaScript for my tastes.

All this client-side programming requires testing too. While sometimes testing using real browsers suits better, tools like Selenium are extremely slow if you have tons of JavaScript to test. So, I was looking for a faster alternative that allowed me to test my client-side code.

Before I present the approach I decided to take, I’d like to warn you that there are lots of good alternatives out there. If you want to take a look at how to use the excellent PhantomJS headless webkit browser, you might be interested in this article.

I decided to go with a solution based on Node.js, a fast runtime JavaScript environment built on top of Google’s V8 engine. Even using Node.js, you’ll find out many good alternatives like Zombie.js, which can also be integrated to the excellent integration test framework Capybara through capybara-zombie. It can also be integrated to Jasmine through zombie-jasmine-spike.

Even though there are great options out there, I still chose another approach for no special reason. The interesting thing about Node.js, is that there’s an interesting ecosystem behind it with tools like NPM which is a package manager for Node, similar to apt on Debian, for instance. On Debian, it can be installed with:

But I would recommend installing just node through apt, and install npm using the instructions here:

The reason for that is that the search command of the npm command provided by the Debian package was not working for me, running the list command instead. Maybe this happens only in the unstable distribution, but I don’t want to get out of the main subject here.

Since we want to test our client-side script, it is necessary to install some library to emulate the browsers DOM, since Node won’t provide one itself. The jsdom library seems to be the de facto standard one for creating a DOM environment.

I don’t really like to read assertions, prefering expectations instead. If you’re like me, you’ll like the Jasmine.js library for writing your expectations in JavaScript. If you don’t want to write integration tests, chances are that you’ll need to mock your AJAX calls. Sinon.js is an excellent framework that will allow you to do that. And since I avoid JavaScript itself at all cost, I’ll write all my examples using CoffeeScript.

If your web framework, differently from Rails doesn’t support CoffeeScript by default, and still you got an interest on this language, you can use Jitter to watch your CoffeeScript files and convert them to JavaScript on the fly. It will replicate your directory structure, converting all your .coffee files to .js:

Install all those dependencies with NPM:

Although you can install jQuery and Sinon.js with ‘npm install jquery sinon’, that won’t make sense, since you’ll want to load them from your DOM environment. So download Sinon.js to your hard-disk to get faster tests.

I don’t practice TDD (or BDD) and I this is a conscious choice. I find it faster to write the implementation first and then write the tests. So, proceeding with this approach, let me show you an example for a “Terms and Conditions” page. Here’s a possible implementation (I’m showing only the client-side part):

Showdown is a JS library for converting Markdown to HTML. Here is the show-terms-and-conditions.coffee equivalent in CoffeeScript:

As you can see, this will issue an AJAX request as soon as the page is loaded. So, we need to fake the AJAX call before we run show-terms-and-conditions.js. This can be easily done with this fake-ajax.js, using Sinon.js:

If you’re not using jQuery, you can try the “sinon.useFakeXMLHttpRequest()” documented in the “Fake XHR” example in Sinon.js site.

Ok, so here is a possible example of specification for this code in CoffeeScript. Jasmine-sinon can help you to write better expectations, so download it to ‘spec/js/jasmine-sinon.js’.

You can run this spec with:

The output should be something like:

Instead of writing “expect($(‘.ui-dialog:visible’).length).toEqual 0”, BDD would advice you to write “expect($(‘.ui-dialog’)).toBeVisible()” instead. Jasmine allows you to write custom matchers. Take a look at my jQuery matchers for an example.

Unfortunately, due to a bug in jsdom, the expected implementations of toBeVisible and toBeHidden won’t work for my cases, where I usually do that by toggling the hidden CSS class (.hidden {display: none}) of my elements. So, I check for this CSS class on my jQuery matchers.

Anyway, I’m just starting to write tests this way. Maybe there are better ways of writing tests like those.

Finally, if you want, you can also set up some auto-testing environment using a tool such as Guard that will watch your JavaScript (or CoffeeScript) files for changes and call jasmine-node on them. Here is an example Guardfile:

If you have any tips, please leave a comment.

Enjoy!