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 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.
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:
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.
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.
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.