- Must be able to run tests from the commend-line
- Tests should be relatively easy to write
However, many share a major flaw: You can’t run tests from the command line. Easily that is.
And not only that.
Various testing libraries that run in the browser require you to fill your tests with cruft that set up a nice HTML document, include the script files, etc. etc.
Out of the various libraries available, Berlios JsUnit, Dojo Object Harness (D.O.H.) and JsTestDriver seemed like the best choices to try out, as they each provided a xUnit’ish feel and allowed command line running.
While this library seemed okay at first, their documentation was a bit scant. I found some examples about tests and running them from the command line, but it seemed a bit labor intensive to load various files manually, and the examples used ActiveX FileSystemObject, so I wasn’t sure whether it would be a good idea to use the library if it wasn’t able to load the scripts without that…
Thus, I left the library on the “backup plan” position in case the two others wouldn’t work out.
Dojo Object Harness
That is, until I read the documentation. The documentation that didn’t exist. I had forgotten how poorly documented Dojo was, and was quickly reminded of it.
Despite this, I decided to try and get the tests running, and to my surprise, the command-line test runner actually ran on the first try. The problems started when I wanted to get my own code loaded into it and tested. Since my code didn’t follow Dojo’s coding style, it seemed next to impossible to get the test runner to figure out where the files were and how to load them.
While the Dojo testing library seems very good, I gave up after a few hours of fighting it and trying to figure out what’s wrong by reading their source code. As usual, nobody on Dojo’s IRC channel had any idea why it didn’t work.
Free tip: Are you making a code library? Do you want it to be popular and widely adopted? Write. Good. Docs.
This was the late-comer to my testing framework list. I randomly spotted it on Miško Hevery’s blog, which is something you must read if you haven’t heard of him. Full of excellent advice on making code testable and various best practices type things.
JsTestDriver seems to be a tool written by Miško and some others, and while it looks simpler than some other alternatives, this is the tool I went with.
Why is JsTestDriver better than the others available? It’s almost perfect, that’s why.
But I said I didn’t want to run tests in browsers. Yes, I don’t want to manually go into the browser and refresh the page to run the tests. The great part about JsTestDriver is that I can open a new tab in the browser, navigate to JsTestDriver’s URL (it has a small server that you run), and simply make the tab a “slave” for testing. After this, I can just forget the browser or use its other tabs for whatever else I want. When I want to run the tests, I simply run the JsTestDriver test runner and it runs my tests in the slave-tab, displaying the results in the command-line.
So while there are many alternatives if you’re not picky about things like command-line running, you’re hopelessly out of luck if you are. I’m glad I managed to spot JsTestDriver since it’s a great tool, but seems it isn’t very widely known.
For great comparisons of various JS unit testing frameworks, I recommend visiting James Carr’s blog. He has written comparisons about many of JS testing tools, and is planning on writing even more.