MacKuba

This year, for several months I’ve been working on a project which involved quite a lot of JavaScript. I’ve already written about how this prompted me to start writing JavaScript unit tests. But as I found out later, there were some kinds of JavaScript errors which the unit tests didn’t help me find. Let me give you an example…

(TLDR: link to the Github project page)

When I work on a Rails web app, I don’t usually test the project in Internet Explorer all the time – if I did that, I’d have gone mad long time ago. Instead, I do everything in Firefox, and leave IE testing for more patient people – either our tester, or even the client in smaller projects. This seems to work well most of the time; however, in this project every 2 weeks or so I used to get such bug report: “The site crashes in IE”. Crashes here means that it doesn’t load at all. You see, if JavaScript is just a nice optional add-on to your project, it’s not a big thing if something doesn’t work; but if your entire application depends on JavaScript for everything it does, then one tiny mistake and you’re screwed.

The problem is that IE has this nasty habit of breaking on code that has a comma at the end of a hash – you know, something like this: { a: 1, b: 2, c: 3, }. And I do this mistake surprisingly often, because that tiny little comma is so easy to miss, and no one ever complains about it except IE – Firefox works fine, unit tests work fine, but next morning I get that dreadful bug report that IE just explodes. Then I wait for VirtualBox to boot Windows and eat all remaining memory, and spend half an hour debugging, only to find that this was all because of one comma…

For the last 3 months I’ve been working on a new web application at work. It’s quite unique in some regards, from the architecture perspective; the biggest difference from other projects that I’ve worked on is that almost entire page is one huge embeddable “widget”. This requires a completely different approach than I usually use:

• a lot of the code above the model layer is moved to the client side (i.e. JavaScript); this means that controllers and helpers are rather simple, controllers mainly return JSON, and there’s quite a lot of JavaScript to write
• since a significant part of the system is written in JavaScript, it needs to be unit-tested too
• I have to be very careful not to cause any JS, CSS or DOM id conflicts between the embedding site and the “widget“ (which includes such things as keeping all JS code in a single global namespace, and using jQuery in the “noConflict extreme“ mode through an alias)

Another thing, which I’d like to write about today, is the way the views were implemented in this project. Since entire GUI is created dynamically by JavaScript, I had basically two options:

• render the views in Rails with ERB and send big chunks of HTML via AJAX to JavaScript;
• or make Rails send only data as JSON, and render the views on the JavaScript side.

I’ve read a lot about good programming practices recently. I’ve read the “Pragmatic programmer” book (which is awesome, one of the most useful books I have read, seriously); I’ve watched a great presentation “Craftsmanship and ethics” by Robert C. Cooper. And it seems that everyone seems to emphasize that one thing that is extremely important to write good software is writing unit tests (and writing them “all the fucking time”, as that black dude said in that presentation ;). I must admit I still haven’t had the courage to switch to TDD (although I try it for single tasks from time to time), and my test coverage is nowhere near what it should be ― it ranges from 20% to 80% depending on the project and its layer. But I know it’s important and I’m working on it…

Anyway, one day I had a thought: even if I test all models and controllers thoroughly, am I not leaving something out? Didn’t I forget about something that is a quite important part of the application ― about my JavaScript code? After all, it’s code too, right? And sometimes it’s very important code; and not having any tests for it means the code is very fragile, it’s easy to break things, already fixed bugs may reappear again, and so on. Of course, JavaScript may be harder to test, because it’s sometimes very closely coupled to HTML, but at least some part of it could surely be tested.

But how do you unit test JavaScript?… I had no idea how to do this.

So I started googling, and I found that there are plenty of different unit test frameworks for JavaScript. Of course I couldn’t resist and I had to take a look at every single one and compare them to choose the best one :) (I heard that it’s called “maximiser” and that it’s bad…). The result of this looking is the list below.