Javascript unit testing options

I want to write some Javascript unit tests. I’d hoped Node.js would be mature enough there was one clear answer from that community, but there’s not. This article was useful but two years old. Here’s some options:

  • Mocha: fancy
  • NodeUnit: simple
  • vows: d3js uses this, but I’ve seen some comments it’s not the fresh choice
  • QUnit: been around a long time, browser oriented

I tried looking at most starred modules and nodejsmodules.org to try to figure out what the cool kids were using but it was too much work.

I’ll probably use Mocha unless it seems too hard to do simple things. It seems particularly crazy that there’s not even a consensus assert module. “There’s more than one way to do things” is usually not a virtue.

 

3 thoughts on “Javascript unit testing options

  1. I’ve been using Mocha + Chai for a project recently (the first bit of serious JavaScript programming I’ve done in years); it’s been going well. The one weirdness so far is that there’s not a super obvious way to define helper functions for a test class; I’ve been attaching them in the before() block, but that sees a little odd. And also sometimes it takes me a little while to figure out the dance for making an assertion about something that’s a builtin object: there’s always a way, the docs are just a little lacking.

    I assume this is for backend work? My project is actually currently on the frontend, but I’m running the unit tests within node anyways, and it works fine for that. (Using browserify helps, so I get require()/exports in both places; also, I’ve had good experiences with Grunt as my build tool.)

    FWIW, I thought James Shore’s recommendations here seemed good / useful: http://www.letscodejavascript.com/v3/blog/2014/03/dependency_recommendations

  2. Thanks for the advice David! That recommendation article is great too. But is it really true if I use browserify it means my code no longer runs in the browser without first having to run some build tool? ugh!

  3. That is true. I worked around that for a while by sticking the CoffeeScript equivalent of

    if (exports) {
    exports.NameOfClass = NameOfClass
    }

    at the end of my source files. These days, I’ve got enough source files with enough dependencies that I’m finding browserify actively helpful for other reasons, but you should be able to do the above until you get to that stage.

Comments are closed.