Test case example as follows (mytest.js):

exports["test1f"] = function(test){
test.expect(1);
test.ok(true, "this assertion should pass");
test.done();
};

exports["test2"] = function(test){
test.ok(true, "this assertion should pass");
test.done();
};

I hope that I can run test2 only like this:

nodeunit test.js test2

Look into adding TAP support using isaac's node-tap module: https://github.com/isaacs/node-tap

Switched from expresso and really like the jscoverage integration so I stole enough code from expresso to display the jscoverage info. Might be nice to include something similar, but better, w/ nodeunit.

The test/fixtures/dir2 directory cannot be walked over without superuser privileges.

It would be good to exclude it from the npm package, since most npm users don't run npm as root, or change the permissions on this folder.

To exclude it from the npm package, add a ".npmignore" file in the root of the nodeunit project containing this line:

test/fixtures/dir2

Because the testsuite checks for hasOwnProperty, adding tests to a testcase dynamically using [...] syntax.

It should be possible to add tests dynamically to a testcase.

Current default outputs color characters that eclispe console does not understand.
I'm trying to integrate nodeunit into an eclispe plugin and all the reporters produce console output that is not readable by a human in the console and difficult to parse by an SWT app

Any plain text output would be useful

Here is a screen shot of the problem http://portawiki.abnoctus.com/view/eclipse-nodeunit-snapshot.png

It would be great to be able to increase test.expect as tests run, so dynamically loaded testing gets easier.

QUnit now adds a tick or cross to document.title, nodeunit should do the same when running in the browser.

I'm curious why vanilla asserts don't get reported by nodeunit? Meaning test.ok(true) counts but assert.ok(true) doesn't get counted. Am I doing something wrong or do I need to hack something? I'd like to use something like should.js but I'd like nodeunit to track the assertions.

Thanks for any advice.

-Mike

FYI, it looks like the NPM install is broken because of an HTTP 404 on http://registry.npmjs.org/nodeunit/-/nodeunit-0.1.0.tgz.

I got to know nodeunit by reading this article http://caolanmcmahon.com/posts/unit_testing_in_node_js which should been written when nodeunit is at earlier phase. It doesn't mention that explicit invocation of callback function in setUp and tearDown.

There is no documentation about which arguments should be sent by invoking callback in setUp and tearDown. So, I suppose, in most cases, callback is just invoked without any arguments.

Why bother to require explicit invocation of this callback? can't it just be invoked by the system after setUp and tearDown is invoked?

Thanks,
-Morgan

Is there any way to know when all of the tests are done, either via an event or via a callback? E.g. you are testing a node app, and are using either a remote service, or another service, etc. There is tearDown for the entire suite (or at least testCase) that you want to perform. setUp is easy, just call it before even setting up the testCase, but what about tearDown?

Conversely, can a testCase have another testCase? e.g.

tests = nodeunit.testCase({
setUp: // some wide setup
tearDown: // some wide teardown
testAll: nodeunit.testCase({
setUp: // per test setup
tearDown: // per test tearDown
testA: function() {... },
testB: function() {... },
testC: function() {... }
})
});

I don't know that this is a nodeunit bug, so much, but it has me stumped.

Using node 0.2.6, I installed nodeunit via npm. When I require nodeunit, though, it blows up:

crapple:node-v0.2.6 kurt$ node
> require('nodeunit')
Error: Cannot find module 'nodeunit'
at loadModule (node.js:275:15)
at require (node.js:411:14)
at cwdRequire (repl:29:10)
at [object Context]:1:1
at Interface. (repl:96:19)
at Interface.emit (events:31:17)
at Interface._ttyWrite (readline:309:12)
at Interface.write (readline:147:30)
at Stream. (repl:79:9)
at Stream.emit (events:31:17)

I have node installed into ~/opt/, all my other npm packages are working fine. Can someone point me in the right direction?

I wonder if it would be better giving t.done() the expected count. I find myself, (as a noobie), doing this:

superdone = ( t, count ) ->
  if t._assertion_list.length < count
    setTimeout( superdone, 20, t, count )
  else
    t.done()

To allow nested callbacks to finish without me having to manually count assertions. Could done() take the count instead?

For me this is a huge issue: I have, not that unexpectedly, thousands of assertions going on in my tests, and so if I change something, this might trigger dozens or even hundreds of them to fail. This is becoming very annoying to handle with nodeunit, because I have to scroll back up through all that "junk" to find out what was the first test that failed and is most likely the root cause. If nodeunit would just have an option to quit right away on the first failed test, testing would be far faster and it would be more easy to use ":! nodeunit test" in vim :).

Group and test names are automatically concatenated into a single string in nodeunit.js... I'd prefer to leave this up to the test reporters, and use an array of property names to identify tests instead.

using: ["group name", "test name"] instead of "group name - test name"

This is an API change which may break some test reporters. The ones included in the nodeunit repository can be easily updated, but others may exist. It might be a good idea to override toString() on the name array so it matches the old format instead of being comma separated.

The README keeps growing and there is more I'd like to add. This probably need splitting into multiple pages. A nodeunit site would be a useful place to share tutorials and API information for the less-simple stuff (custom reporters for example).

Nodeunit always returns an exit status 0, disregarding if there are failing tests. This troubles my continuous integration system (Jenkins) which performs a build and runs my tests. Jenkins verifies if the commands it executes in the build return a nonzero status code, which means the execution encountered problems. Now I need to grep the output to check for failures and mark my build as failed.

I'm working on a patch for this (https://github.com/munkius/nodeunit)

I get the following stack trace when trying to use nodeunit under node 0.5.2. Apparently require.paths is no longer valid.

node.js:195
        throw e; // process.nextTick error, or 'error' event on first tick
              ^
Error: require.paths is removed. Use node_modules folders, or the NODE_PATH environment variable instead.
    at Function.<anonymous> (module.js:360:11)
    at Object.<anonymous> (/Users/michael/.local/node/lib/node_modules/nodeunit/bin/nodeunit:13:8)
    at Module._compile (module.js:420:26)
    at Object..js (module.js:459:10)
    at Module.load (module.js:335:31)
    at Function._load (module.js:294:12)
    at Array.<anonymous> (module.js:479:10)
    at EventEmitter._tickCallback (node.js:187:26)

deepEquals does not take into account objects/object instances that will implicitely cast to primitive values using valueOf or toString(). For example:

rkieffer@rkieffer-mbp$ pwd
/Users/rkieffer/repos/nodeunit

rkieffer@rkieffer-mbp$ node
> assert = require('./lib/assert.js')
{ AssertionError: { [Function: AssertionError] super_: { [Function: Error] captureStackTrace: [Function: captureStackTrace], stackTraceLimit: 10 } },
  fail: [Function: fail],
  ok: [Function: ok],
  equal: [Function: equal],
  notEqual: [Function: notEqual],
  deepEqual: [Function: deepEqual],
  notDeepEqual: [Function: notDeepEqual],
  strictEqual: [Function: strictEqual],
  notStrictEqual: [Function: notStrictEqual],
  throws: [Function],
  doesNotThrow: [Function],
  ifError: [Function] }
> x = {foo: {valueOf: function() {return 9;}}}
{ foo: { valueOf: [Function] } }
> y = {foo: 9}
{ foo: 9 }
> x.foo == y.foo
true
> assert.deepEqual(x, y)
AssertionError: {"foo":9} deepEqual {"foo":{}}
    at [object Context]:1:8
    at Interface.<anonymous> (repl.js:98:19)
    at Interface.emit (events.js:27:15)
    at Interface._ttyWrite (readline.js:307:12)
    at Interface.write (readline.js:145:30)
    at Stream.<anonymous> (repl.js:76:9)
    at Stream.emit (events.js:27:15)
    at Stream._onReadable (net.js:757:14)
    at IOWatcher.onReadable [as callback] (net.js:276:10)
> 

Or rather, why not the best?

I'm getting fed up with some sillinesses of QUnit. I'm currently considering my options for good front end test framework, and since I'm using Nodueinit for my back end code, I thought, why not use it for the client side as well? I gave it a try, and liked the fact that it worked, but I didn't like it's report output.

So, I thought why not improve upon it, and it could easily be the best FE unittesting framework out there.

I'm writing to you because I'd like to hear you thoughts about it, discuss our ideas, so that you'll be able to pull it back happily not resulting in us branching out to 2 separate projects.

Here are my initial thoughts:

• Be AMD (Asynchronous Module Definition) compatible, but provide functional fall back code if one wants to load it with <script> tags.
• Have wonderful reporting UI, both in terms of functionality and look!

What do you think? Ever thought about improving the FE reporter/support? What ideas do you have?

Hello,

I noticed test.throws in nodeunit is not working the same as the node 0.4.11 assert.throws detailed here: http://nodejs.org/docs/v0.4.11/api/all.html#assert.throws

I am using nodeunit 0.5.4.

I will be sending a pull request shortly...

When calling npm update, npm should skip any packages and continue on with the rest instead of stopping.

For example im still running node v0.2.4, node-inspector required v0.3.0 but that shouldn't stop the rest of the packages from updating.

This should allow the watching of both lib and test directories and re-run tests when any changes occur. Perhaps make use of mikeal's watch module? https://github.com/mikeal/watch

Is there a way to check, if an array contains all elements disregarding the order?
I've written a function to check for it, because I needed it with asynchronous test results. My function uses the indexOf-function of arrays.

The version is read from package.json, which is not copied to the install path during 'make install'. Version reporting still works when nodeunit is installed via npm.

The nodeunit tests for me hang after test-runtest.js/testThrowError:

% ./test.js

/Users/sam/Projects/nodeunit/test/test-base.js
✔ testCalled
✔ testOk
✔ testEquals
✔ testSame
✔ testExpect

/Users/sam/Projects/nodeunit/test/test-runfiles.js
✔ testRunFiles
✔ testRunFilesEmpty
✔ testEmptyDir

/Users/sam/Projects/nodeunit/test/test-runmodule.js
✔ testRunModule
✔ testRunModuleEmpty

/Users/sam/Projects/nodeunit/test/test-runtest.js
✔ testArgs
✔ testDoneCallback
✔ testThrowError
<hang>

Doing 'nodeunit path_does_not_exist' reports no errors but a successful test run of 0 assertions. This seems wrong.

I need an option to bypass all calls to process.reallyExit() as I am wrapping nodeunit in a build tool.

the word default is keyword and being flagged as such in eclipse. I was wondering if this could be renamed.

When I try to redirect the test reporter's output to a file by doing:

./bin/nodeunit test > report.txt

the file doesn't contain all the report information, even though it is always printed to the console when run normally. This affects all test reporters, and happens with every test suite I've tried.

I had plan to implement some of these features, but though it might be good to discuss them with you first.

possibility to mark a test as TODO

Sometimes you want to create a test before you actually implement the feature (there is a school for that), and it might be useful to be able to mark a test as TODO.
This pretty much invert the truth value of a test, so it will fail if it succeeds, and vice versa.
Also in the output, it should mark the TODO in a nice way in the testrunner

ability to skip tests

You might want to conditionally skip a test. Gonna list some examples, some that might be just syntactical sugare, and some needs more intelligence:

• A test should not be run if a test that tests relevant dependency fails
• A test might not be testable if no network connection exists
• A test might be expensive is computation, and might not be run often
• A test might not be applicable on certain hardware

A sub type of skip could also be to be able to skip the test of a whole group if a test fails, but still test all other tests.

Group naming

at the moment, the group naming is made in nodeunit.js, i.e. the concatenation with ' - '. I would recommend it's been moved out to the testrunner code instead, so the display can be customized.

Removal of stacktrace

Haven't looked into this much, but I wonder if there is a way to remove all stacktraces of failed tests, as they are seldom useful, as it's the trace in the test code, and not in the tested code.

I have some nodeunit tests which run fine when run in console mode

jerome@mofo:~/project/abc/server/node$ nodeunit test/

httpd-server-test
✔ test http handles request to our callback and req.content mapped POST data

telemetry-test
✔ test mapping of inbound params to analytics
✔ test digesting multiple inbound messages
✔ test handles corrupt message
✔ test get path assembly
✔ test successful message dispatch
✔ test failed message dispatch
✔ test listener instance init
✔ test listener hotplugging on remoteSite up/down
✔ test uptime checking mechanism
✔ test failed message is queued
✔ test queued message is delivered on resume

OK: 31 assertions (36ms)
jerome@mofo:~/project/abc/server/node$

However when I run the same tests in report output mode, it doesn't graceful exit anymore.. I have to CTRL-C it.. obviously this is a problem for the CI.. Is there something that might be causing it?

jerome@mofo:~/project/abc/server/node$ nodeunit --output ../reports --reporter junit test/
Writing /home/jerome/project/abc/server/reports/httpd-server-test.xml
Writing /home/jerome/project/abc/server/reports/telemetry-test.xml

OK: 31 assertions (35ms)

^Cjerome@mofo:~/project/abc/server/node$

Add command-line options for running each module in parallel, or each test in parallel in a single process. Or the option to run each module in parallel in separate processes (to help with mocking).

Following test hangs with 0.5.3 but works with 0.5.1

var net = require('net');


exports['init-conn-test'] = function (test) {
    var someServer = net.createServer();
    var port = 1122;

    var done = false;

    var interval = setInterval(function() {
        if (!done) {
            test.ok(false, 'init-conn-test is expected to finish in 3 secs');
            test.done();
        }
        try {
            someServer.close();
        }
        catch(e) {
            // eat it
        }
        clearInterval(interval);
    }, 3000);

    someServer.on('connection', function(sock) {
        sock.on('data', function(data) {
            lastEvent = data;
            test.deepEqual(data.toString(), 'Testing123');
            try {
                someServer.close();
            }
            catch(e) {
                // eat it
            }
            done = true;
            clearInterval(interval);
            test.done();
        })
    });

    someServer.listen(port, 'localhost', function() {
        var socket = net.createConnection(port, 'localhost');
        socket.write('Testing123');
    });
};

I think it would be useful to have something like --include=PATH for the CLI testrunner. That way you can setup your testsuite without having to know about the actual location of the test suite in the directory structure. The call to the CLI testrunner then can take care of setting up the enviroment using --include. No need to repeat

require =("../lib/LibrarySubjectToBeTested");

but do

require('LibrarySubjectToBeTested"); 

and simply call

nodeunit --include=../lib/

I implemented a patch that would add this functionality to the testrunner. Have a look at it: 1db0b28
Please let me know what you think and if there's anything I missed. If you like it, feel free to pull it in.

Install FAIL when I tried to use the 'npm' install method.

Command: npm install nodeunit (output show at the end of this post).

A work around is to use sudo npm install nodeunit, as notice by
isaacs (https://github.com/caolan/nodeunit/issues/issue/44).

But, I do not understand, why 'nodeunit' require such powerful privilege as sudo ?

I can see the origin of the problem in the tar file, it is the dir test/fixtures/dir2/ which have some special permission restriction:

...
drwxr-xr-x  0 caolan caolan      0 22 Nov 05:00 nodeunit/test/fixtures/
-rw-r--r--  0 caolan caolan     31 22 Nov 05:00 nodeunit/test/fixtures/mock_module1.js
dr----x--t  0 caolan caolan      0 22 Nov 05:00 nodeunit/test/fixtures/dir2/
-rw-r--r--  0 caolan caolan     57 22 Nov 05:00 nodeunit/test/fixtures/raw_jscode2.js
...

Can you change the permission of this directory to something more friendly, so we can use 'npm' without the sudo command?

Thanks.

npm install nodeunit
npm info it worked if it ends with ok
npm info using [email protected]
npm info using [email protected]
npm info fetch http://registry.npmjs.org/nodeunit/-/nodeunit-0.5.0.tgz
npm ERR! Failed creating the tarball.
npm ERR! This is very rare. Perhaps the 'gzip' or 'tar' configs
npm ERR! are set improperly?
npm ERR!
npm ERR! Error installing [email protected]
npm ERR! Error: Failed tar "cvf" "-" "--exclude" ".git" "-X" "/Users/seb/local/lib/node/.npm/npm/0.2.8-1/package/lib/utils/default.npmignore" "1290628063645-0.4788051717914641"
npm ERR! exited with 1
...

Dear caolan

Using nodeunit in windows works fine. But the sign for "success" and "error" comes as a "?" in the windows console. Would be nice, if you could use a valid sign for each console (or maybe check the environment and puts a different sign).

Thanks a lot,
Joachim

In nodeunit, whenever you call

nodeunit.reporters["default"].run(["a","b"]);

it will always, eventually, require("a") as a test and run it, then require("b") and then run it.

What if you want to load files on your own, or even define tests in memory, never saving to a file? As an example, I could see loading a file, doing some manipulation, and only then passing it through to nodeunit.

In this scenario, the two run() calls below would be equivalent:

var a = require("a");
nodeunit.reporters["default"].run(["a"]);
nodeunit.reporters["default"].runModule(a);

But the second option gives me the ability to do:

var a = require("a");
a.doSomeMod();
nodeunit.reporters["default"].runModule(a);

Even better, you don't need runModule. All you need is for run() to check each option in the array; if it is a string, require() it as a file, else just use it as is.

Whole change set could probably be done in nodeunit.js ll 61-81.

Currently .js files directly in the target directory are run, sub directories are ignored. This is useful if you have a fixtures directory inside your tests directory, but might be annoying if you're working on a large project with lots of tests...

thoughts?

Hi,

I'm writing some unit tests for Meryl, and have progressed a bit. You may know that Meryl is a web framework and as you guess i want to test http responses for given http requests something like http://httpunit.sourceforge.net/doc/servletunit-intro.html

I had written an utility for testing Meryl as a result of my needs but it is so straightforward.

http://github.com/coffeemate/meryl/tree/master/test/

I want something more complicated (such using 'async' framework for http requests) but if i work on a more complex utility, i won't want it to use only in Meryl but also Meryl-Extras. So i had needed a more generic utility and looked for nodeunit if i can extend it in some way.

Currently there is no way (i guess so) to extend test object.
http://github.com/caolan/nodeunit/blob/master/lib/types.js#L126

I just imagine something like the pseudo code below

http://gist.github.com/621957

var async = require('async');
var meryl = require('meryl');

exports.testSomething = function (test) {
    test.http (
        meryl.h('GET /', function(req, resp) {resp.send('test data');}).cgi(),
        function (server, client) {
            async.series([
                function (callback) {
                    client.request('GET', '/', {'Host': 'localhost'}, function (resp) {
                        test.equal(resp.statusCode, 200);
                        test.equal(resp.body, 'test data');
                        callback();
                    });
                },
                function (callback) {
                    client.request('GET', '/absent', {'Host': 'localhost'}, function (resp) {
                        test.equal(resp.statusCode, 404);
                        callback();
                    });
                },
                function (callback) {
                    test.done();
                    server.close();
                    callback();
                }
            ]);
        }
    );
}

So what can be the adequate solution? Any point of way or idea? Should i implement this on my own works only or adapt nodeunit in some way?

Also Expresso has assert.response but it is not satisfactory enough imho.
http://github.com/visionmedia/expresso/blob/master/bin/expresso#L338

Simple test case:

module.exports = {
  1: function(test) { test.ok(1) },
  2: function(test) { test.ok(1); test.done() }
}

The runner dies after test 1 with exit code 0, indicating no failures. Even more confusing is that the last line of runner output shows the name of the previous test, not the test that failed to finish.

This is a big pain when testing async code where the call to test.done() is in a callback. Of course, if the code is right, the callback should be fired, but that's not why we're writing tests :)

Can the runner install a process.on('exit') handler that prints a message and sets the exit code if it's waiting on a call to test.done()?

This is useful for check error cases in tests, instead of
var flag = false;
try {
smth();
} catch(e) {
flag = true;
}
test.ok(flag, ...);

If you haven't time for this or have some arguments contra, I can add this in the fork.

It would be great if you could provide a -r option to the command-line nodeunit program, so that the directory you give it is recursively searched and all tests in all subdirectories are ran. Thanks!

the third param of the junit reporter's run method is a callback. that call back function is never actually called.

The other reporters don't actually accept a callback, but they should.

There is a lot of nodeunit and async.js noise in the stacktraces... If we can reliably improve the stacktraces, it would make debugging failing tests a little nicer.

I'm a bit worried about messing with something as fundamental as a stacktrace, but it might be worth experimenting with, and could be included as an option to the command line tool at first.

See: http://code.google.com/p/v8/wiki/JavaScriptStackTraceApi

There are pull requests going back to December '10. Is this project being maintained?

Hello, i can't get any response from nodeunit installed by npm.

> npm install nodeunit
  ... install ok
> nodeunit
  .. no response
> nodeunit exampletest.js
  .. no response

Missing something? Currently trying on Macosx 10.5.8.

Bleeding version via git one responds

> git clone http://github.com/caolan/nodeunit.git; cd nodeunit
> ./nodeunit 
readlink: illegal option -- f
usage: readlink [-n] [file ...]
usage: dirname path

fs:150
  return binding.open(path, stringToFlags(flags), mode);
                 ^
Error: ENOENT, No such file or directory '/../lib/testrunner.js'
    at Object.openSync (fs:150:18)
    at Object.readFileSync (fs:94:15)
    at Module._loadScriptSync (node.js:467:39)
    at Module.loadSync (node.js:338:12)
    at Object.runMain (node.js:521:24)
    at node.js:751:10

Best.

This is a concept used in phpunit(i assume junit too since phpunit was inspired by junit). Basically every test within a test case has an optional data provider that gets linked up to it if available. PHPUnit does this through reflection since there isn't any good reflection implementations for javascript that I know of i think using convention is appropriate. Here's my proposal:

exports = testCase({
'provider test1':function(){
   return [
     [foo,bar],//test1
     [baz,gah],//test2
]

},
'test test1':function(test,value,expected){
    if(value == 'foo') test.equal('bar',expected);
    else if(value == 'baz') test.equal('baz',expected);

}

});

The nuance of the above code is the 'test test1' is run twice once passing 'foo' and 'bar' and then again passing 'baz' and 'gah'. You could write multiple test cases to support each row in the data provider but that gets a little verbose and this method is cleaner i think.

This obviously has API implications, and certain conventions would have to be adopted, so I wanted to have a discussion before looking into implementations. Sorry if this has been discussed, or has a current implementation i didn't see any.