Which JavaScript Test Library Should You Use? QUnit vs Jasmine vs Mocha

Whether you’re writing javaScript for the browser or for nodeJS, the question exists: what unit test library should I use to ensure my javascript code is working as expected?  There are plenty to choose from, and several that are popular.  If you were considering jUnit, Jasmine, or Mocha, then I’ve got some information you might be interested in: the good, the bad, and the ugly.

qUnit

qUnit is definitely the oldest of the three on my list, having its first official release in 2008.  Because of this, it has picked up a good userbase over the years.  It’s seen popular use in jQuery, and has amazing support from a lot of places.

How does it stack up?  It’s really not pretty…

Pros:

  • Lots of support across the board, from Q&A to CI server support

Cons:

  • Lacks fluent syntax
  • Configuration is a headache, and must constantly be maintained
  • Makes including 3rd party libraries (like assertion libraries) relatively difficult
  • Asynchronous testing can be a bit of a headache
  • No baked-in headless run support

Jasmine is slightly newer to the pack, having been released 2 years after qUnit in 2010.  It’s on the edge of having had enough time to mature, while still having learned the lessons of other JavaScript test frameworks.  It’s built to be easy to set up and use in almost any scenario.  It requires a runner, such as Karma or Chutzpah, in most scenarios, but some distros (like the jasmine-node npm) have one baked in.

How’s it look?  It’s pretty nice for most scenarios you could want, asynchronous code being the main problem area.

Pros:

  • Simple setup for node through jasmine-node
  • Headless running out of the box
  • Nice fluent syntax for assertions built-in, and does play pretty well with other assertion libraries
  • Supported by many CI servers (TeamCity, Codeship, etc.) and some that don’t support natively have plugins (jenkins has a maven plugin)
  • Descriptive syntax for BDD paradigm

Cons:

  • Asynchronous testing can be a bit of a headache
  • Expects a specific suffix to all test files (*spec.js by default)

Having been built specifically for testing nodeJs modules, Mocha is the baby of the bunch with its first major build released in 2012.  Its API is rather similar to that of Jasmine’s, with a bit of syntactic sugar added to make it more conductive to a wider range of scenarios, such as BDD. It has its own test runner baked in, so that’s a concern you should never have to worry about.  It also, unlike Jasmine, has really nice support for testing asynchronous methods, using the done() function: if your test uses it, the test doesn’t pass until done() is called, if it doesn’t use it, the test will pass when it reaches the end of the test method.

My impression?  Looks pretty darn good to me!

Pros:

  • Simple setup
  • Headless running out of the box
  • Allows use of any assertion library that will throw exceptions on failure, such as Chai
  • Supported by some CI servers and plugins for others (jenkins has a maven plugin)
  • Has aliases for functions to be more BDD-oriented or TDD-oriented
  • Highly extensible
  • Asynchronous testing is a breeze

Cons:

  • Newer to the field, so support might be lacking in certain areas

TL;DR

Looking at the three options above, my choice is clear: Mocha far and above has the easiest configuration, most flexibility, and best usability.  Out-of-the-box, it does everything you need it to, and does so elegantly.

If you’re interested in seeing a simple example of each one of these three frameworks in action, check out the repo I created when researching:
https://github.com/thegrtman/javascript-test-framework-comparison

Feel free to let me know how you feel about my results, or if I’ve missed anything.

kgroat09

Kevin Groat is a .NET and JavaScript developer, with a strong passion of clean, elegant code. Working as a Consultant at Excella Consulting has given him experience in creating and consuming RESTful