First few stabs at Chai

Continuing on my investigation of what’s what in the state of Javascript testing frameworks, I downloaded Chai and ported several of my existing Qunit tests over to it. Chai is more or less a plugin for Mocha, which is a test harness framework that allows you to organize your tests, while leaving the meaty assertion bits of testing to outside libraries. The decoupling of these two aspects of a testing framework seems like a pretty neat approach, and I may investigate some of the other assertion plugins available for Mocha besides Chai in the future, assuming I’m not completely burnt out on testing frameworks by then. Meanwhile, Chai itself has a plugin infrastructure, with hooks available that expand its vocabulary or integrate it with other libraries such as jQuery and Backbone.

I haven’t got too far yet, but I think I can safely say that I’m not in love with the syntax. Chai exposes two main verbs, which do about the same thing. expect(foo); is the more obvious syntax; optionally Chai can instead attach the function should() to the global Object prototype, which allows assertions like this:;. Overall combined with Mocha’s BDD test style, you wind up with code like this:

describe('WeightedList', function() {

  describe('Constructor', function() {
    it('should succeed with no arguments', function() {
      expect(new WeightedList());

  describe('Empty List', function() {
    var wl = new WeightedList();

    it('should have length zero', function() {

    it('should give an empty list on shuffle', function() {

I suppose it’s readable enough, maybe I just still haven’t gotten over Javascript’s relentless use of function(){} blocks.   I will say that seeing some similar tests (but for Jasmine, a competing framework) written in CoffeeScript is certainly easier on the eyes.

Error reportIn any event, despite my trepidation at the syntax, Chai has already helped me in one way I hadn’t expected: it found a bug in my code.  Running the test that calls shuffle on an empty list, the test runner produced the error “Error: global leaks detected: heap, result.”  Sure enough, looking at my code, I’d left off the var declarations from two variables in one of the inner methods there.  Adding in the var statements caused the test to pass again.  Thanks Chai!  As I experiment with other frameworks I might try taking the declarations out again to see whether anyone else will catch the same thing.


Leave a comment

1 Comment

  1. Forging on with javascript testing frameworks « Tim Gilbert's Blog

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: