There are currently two branches for CLI integration, one covering node.js and Rhino, one covering PhantomJS. As such they aren't very useful. They need to be merged to master and published in an appropiate format, e.g. as npm module for node, Narwhal for Rhino?.
There's also a separate project maintained by John Dalton, qunit-clib, providing integration into various enviroments.
PhantomJS
PhantomJS is pretty useful to run QUnit tests that target a browser environment in a continuos integration setup. The recent 1.2.0 release broke the existing runner due to heavy API changes, but there's a ticket to get that fixed.
They bundle their own runner, but its not good. Doesn't log any assertions, reads result by looking at the DOM elements instead of using the callbacks.
PhantomJS can also be useful to run tests locally, in combination with a file watcher. Would be interesting to port this to something more cross-platform, e.g. nodejs (now also kind of working on Windows, getting better).
Another option to run QUnit tests on the server, using node.js and jsdom to simulate the browser enviroment.
node.js/npm
For distribution via npm, the package.json file needs a version property, and likely some other updates. In order to write tests with QUnit on node.js, there's some more going on that needs to be explored.
An interesting idea would be to reuse the browser-based testrunner, as an output for running node.js tests. QUnit would have to include a simple webserver that outputs the testresults in its usual markup and loads qunit.css to style it.
There are already plenty of testing modules for node.js, among them:
- node-qunit, a port of QUnit
- foounit, targets more then just node.js, e.g. browsers
- jasmine-node, node module for jasmine integration
- node-async-testing, focus on async tests, also an important QUnit feature
- nodeunit, a more popular node unit testing framework, tests are defined as exports
It should be possible to run QUnit tests that don't depend on the browser to run on the command line. To figure out how to do that, add a headless test build step for globalize.
qunit-clib
John-David Dalton wrote a CLI wrapper for QUnit for various CLI enviroments, called qunit-clib. In addition to the docs in the readme there's also an example from benchmark.js.
This looks like a very useful starting point for something to integrate into QUnit itself.
Usefulness?
Currently its not quite clear how useful CLI integration actually is. PhantomJS can be used to run tests written for a browser, while node.js integration would be more about testing serverside code. That's clearly not a strength of QUnit right now, and probably will never be, especially considering all the specialized frameworks already available in that context. Instead QUnit should probably focus on integration scenarios that are relevant in the browser, such as better event simulation or interactions with canvas or SVG.
Comments (1)
Jonathan Buchanan said
at 9:23 am on Jul 27, 2011
I think CLI integration needs a way to define how dependencies, code under test and tests should be imported equivalent to what you would do in the HTML test runner.
I have some cross-environment libraries which have tests written against the way they expose themselves for use in the browser, where each module adds a single variable to the global scope. To use those same tests on Node, I needed a way to specify that modules are required into a specific variable name, which is exposed to the tests. I made some changes to node-qunit which make this possible - this is what an HTML test runner and its equivalent node-qunit test module look like right now:
https://github.com/insin/newforms/blob/master/tests/tests.html
https://github.com/insin/newforms/blob/master/tests/tests.js
node-qunit runs each test module asynchronously, but it redefines QUnit to use some of Node's equivalent built-in assertions, so I'm hoping there's a nice way to integrate something similar into QUnit proper.
You don't have permission to comment on this page.