A Critique of the Thoughtworks Tech Radar on Javascript Testing

kant2

The Thoughtworks' Tech Radar has come out again and there is no change in the recommendation on Javascript testing.

The radar recommends to "Adopt Jasmine paired with Node.js". This is very specific advice. It's not "Adopt Javascript testing paired with Node.js" but a specific tool, Jasmine. Compare this with more general advice such as "Adopt CSS Frameworks" or "Promises for asynchronous programming". Nothing specific there and, hence, nothing wrong.

There is no motivation as to why we should adopt Jasmine but, if we look at the TTF from October 2012(PDF), we can read:

The cream of the crop for out-of-browser testing is currently Jasmine. Jasmine
paired with Node.js is the go-to choice for robust testing of both client- and
serverside JavaScript.

"The cream of the crop"? This is certainly not the case! Jasmine is an elegant testing framework similar Ruby's RSpec but, it is not "the cream of the crop"! It has one major drawback. It sucks at testing asynchronous code! And, since asynchronous code is a central theme in Javascript programming we should not use Jasmine! There are at least two better alternatives:

Example

In this example I want to test is a simple asynchronous sort function called sleepsort, you can read more about it in Writing a Module.

The function signature looks like this:

Testing this with Jasmine will look something like this:

This is horrible! Compare this to Mocha, with should.js assertions:

Thank you, Sir, may I have another!

Indeed you may, here it is with Buster.js, with Object style syntax:

Both Mocha and Buster.js send in a done function to call when the execution has finished. Elegant, and above all crystal clear.

It is very obvious to me that Jasmine no longer is "the cream of the crop" of Javascript testing. But, what do I know, perhaps it was a copy-paste error.

I've done my duty, now I can go to bed!

Duty Calls from XKCD

5 Comments

  1. Another possiblity is to manage your asynchronous code with an FRP library like Rx.js or Bacon.js in the first place.

    These have the added benefit of supporting a scheduler abstraction, which can basically convert your milliseconds into “ticks”.

    See for instance https://github.com/raimohanska/bacon.js/blob/master/spec/BaconSpec.coffee for a heavily asynchronous test suite that both uses Jasmine and runs really fast.

  2. @Philip, I agree that you can certainly write code that is easily testable with Jasmine. And, I agree that reactive extensions yields very nice code.

    But, most Javascript written today uses the asynchronous callback style, and this is not readably testable with Jasmine.

    My point doesn’t change, ‘Jasmine is not “the cream of the crop” of Javascript testing.

  3. Oh, no just adopted Jasmine in our project. Mainly because we could find a way to run Jasmine testcases in TeamCity. Do you know if there is a solution for running Mocha or Buster.js in our TeamCity CI environment?

  4. foob

    > quote

    See for instance https://github.com/raimohanska/bacon.js/blob/master/spec/BaconSpec.coffee for a heavily asynchronous test suite that both uses Jasmine and runs really fast.

    < quote

    Man, what a huge mess that code is!

Leave a Reply