Giter Site home page Giter Site logo

nodeunit's Introduction

Nodeunit

Build Status

Simple syntax, powerful tools. Nodeunit provides easy async unit testing for node.js and the browser.

DEPRECATED PROJECT

The project is very stale. We've kept it working on new versions of node, and sometimes merged small PRs that help teams relying on nodeunit.

Nodeunit was the arguably first testing framework developed for node. It was very useful at the time, but there's an overwhelming number of other worthwhile testing solutions out there that are actively maintained. tap, ava, tape, mocha, jasmine, jest, ... the list goes on and on.

If Nodeunit were truly bringing some different philosophy to the testing scene I'd say yes effort should be made to shore up it's development, but given how many other great options there are out there, a benefit of letting it atrophy is it's one less choice people have to make when choosing a testing solution. You are strongly encouraged to check out other more modern testing options.

Features

  • Simple to use
  • Just export the tests from a module
  • Works with node.js and in the browser
  • Helps you avoid common pitfalls when testing asynchronous code
  • Easy to add test cases with setUp and tearDown functions if you wish
  • Flexible reporters for custom output, built-in support for HTML and jUnit XML
  • Allows the use of mocks and stubs

Contributors

Also, check out gerad's nodeunit-dsl project, which implements a 'pretty dsl on top of nodeunit'.

More contributor information can be found in the CONTRIBUTORS.md file.

Usage

Here is an example unit test module:

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

exports.testSomethingElse = function(test) {
    test.ok(false, "this assertion should fail");
    test.done();
};

When run using the included test runner, this will output the following:

Installation

There are two options for installing nodeunit:

  1. Clone / download nodeunit from github, then:

    make && sudo make install

  2. Install via npm:

    npm install nodeunit -g

API Documentation

Nodeunit uses the functions available in the node.js assert module:

  • ok(value, [message]) - Tests if value is a true value.
  • equal(actual, expected, [message]) - Tests shallow, coercive equality with the equal comparison operator ( == ).
  • notEqual(actual, expected, [message]) - Tests shallow, coercive non-equality with the not equal comparison operator ( != ).
  • deepEqual(actual, expected, [message]) - Tests for deep equality.
  • notDeepEqual(actual, expected, [message]) - Tests for any deep inequality.
  • strictEqual(actual, expected, [message]) - Tests strict equality, as determined by the strict equality operator ( === )
  • notStrictEqual(actual, expected, [message]) - Tests strict non-equality, as determined by the strict not equal operator ( !== )
  • throws(block, [error], [message]) - Expects block to throw an error.
  • doesNotThrow(block, [error], [message]) - Expects block not to throw an error.
  • ifError(value) - Tests if value is not a false value, throws if it is a true value. Useful when testing the first argument, error in callbacks.

Nodeunit also provides the following functions within tests:

  • expect(amount) - Specify how many assertions are expected to run within a test. Very useful for ensuring that all your callbacks and assertions are run.
  • done() - Finish the current test function, and move on to the next. ALL tests should call this!

Nodeunit aims to be simple and easy to learn. This is achieved through using existing structures (such as node.js modules) to maximum effect, and reducing the API where possible, to make it easier to digest.

Tests are simply exported from a module, but they are still run in the order they are defined.

Note: Users of old nodeunit versions may remember using ok, equals and same in the style of qunit, instead of the assert functions above. These functions still exist for backwards compatibility, and are simply aliases to their assert module counterparts.

Asynchronous Testing

When testing asynchronous code, there are a number of sharp edges to watch out for. Thankfully, nodeunit is designed to help you avoid as many of these pitfalls as possible. For the most part, testing asynchronous code in nodeunit just works.

Tests run in series

While running tests in parallel seems like a good idea for speeding up your test suite, in practice I've found it means writing much more complicated tests. Because of node's module cache, running tests in parallel means mocking and stubbing is pretty much impossible. One of the nicest things about testing in javascript is the ease of doing stubs:

var _readFile = fs.readFile;
fs.readFile = function(path, callback) {
    // it's a stub!
};
// test function that uses fs.readFile

// we're done
fs.readFile = _readFile;

You cannot do this when running tests in parallel. In order to keep testing as simple as possible, nodeunit avoids it. Thankfully, most unit-test suites run fast anyway.

Explicit ending of tests

When testing async code it's important that tests end at the correct point, not just after a given number of assertions. Otherwise your tests can run short, ending before all assertions have completed. It's important to detect too many assertions as well as too few. Combining explicit ending of tests with an expected number of assertions helps to avoid false test passes, so be sure to use the test.expect() method at the start of your test functions, and test.done() when finished.

Groups, setUp and tearDown

Nodeunit allows the nesting of test functions:

exports.test1 = function (test) {
    ...
}

exports.group = {
    test2: function (test) {
        ...
    },
    test3: function (test) {
        ...
    }
}

This would be run as:

test1
group - test2
group - test3

Using these groups, Nodeunit allows you to define a setUp function, which is run before each test, and a tearDown function, which is run after each test calls test.done():

module.exports = {
    setUp: function (callback) {
        this.foo = 'bar';
        callback();
    },
    tearDown: function (callback) {
        // clean up
        callback();
    },
    test1: function (test) {
        test.equals(this.foo, 'bar');
        test.done();
    }
};

In this way, it's possible to have multiple groups of tests in a module, each group with its own setUp and tearDown functions.

Running Tests

Nodeunit comes with a basic command-line test runner, which can be installed using sudo make install. Example usage:

nodeunit testmodule1.js testfolder [...]

If no entry file specified, test defaults.

The default test reporter uses color output, because I think that's more fun :) I intend to add a no-color option in future. To give you a feeling of the fun you'll be having writing tests, lets fix the example at the start of the README:

Ahhh, Doesn't that feel better?

When using the included test runner, it will exit using the failed number of assertions as the exit code. This means it exits with 0 when all tests pass.

Command-line Options

  • --reporter FILE - you can set the test reporter to a custom module or on of the modules in nodeunit/lib/reporters, when omitted, the default test runner is used.
  • --list-reporters - list available built-in reporters.
  • --config FILE - load config options from a JSON file, allows the customisation of color schemes for the default test reporter etc. See bin/nodeunit.json for current available options.
  • -t testName - run specific test only.
  • -f fullTestName - run specific test only. fullTestName is built so: "outerGroup - .. - innerGroup - testName".
  • --version or -v - report nodeunit version
  • --help - show nodeunit help

Running tests in the browser

Nodeunit tests can also be run inside the browser. For example usage, see the examples/browser folder. The basic syntax is as follows:

test.html

<html>
  <head>
    <title>Example Test Suite</title>
    <link rel="stylesheet" href="nodeunit.css" type="text/css" />
    <script src="nodeunit.js"></script>
    <script src="suite1.js"></script>
    <script src="suite2.js"></script>
  </head>
  <body>
    <h1 id="nodeunit-header">Example Test Suite</h1>
    <script>
      nodeunit.run({
        'Suite One': suite1,
        'Suite Two': suite2
      });
    </script>
  </body>
</html>

Here, suite1 and suite2 are just object literals containing test functions or groups, as would be returned if you did require('test-suite') in node.js:

suite1.js

this.suite1 = {
    'example test': function (test) {
        test.ok(true, 'everything is ok');
        test.done();
    }
};

If you wish to use a commonjs format for your test suites (using exports), it is up to you to define the commonjs tools for the browser. There are a number of alternatives and it's important it fits with your existing code, which is why nodeunit does not currently provide this out of the box.

In the example above, the tests will run when the page is loaded.

The browser-version of nodeunit.js is created in dist/browser when you do, make browser. You'll need UglifyJS installed in order for it to automatically create nodeunit.min.js.

Adding nodeunit to Your Projects

If you don't want people to have to install the nodeunit command-line tool, you'll want to create a script that runs the tests for your project with the correct require paths set up. Here's an example test script, that assumes you have nodeunit in a suitably located node_modules directory.

#!/usr/bin/env node
var reporter = require('nodeunit').reporters.default;
reporter.run(['test']);

If you're using git, you might find it useful to include nodeunit as a submodule. Using submodules makes it easy for developers to download nodeunit and run your test suite, without cluttering up your repository with the source code. To add nodeunit as a git submodule do the following:

git submodule add git://github.com/caolan/nodeunit.git node_modules/nodeunit

This will add nodeunit to the node_modules folder of your project. Now, when cloning the repository, nodeunit can be downloaded by doing the following:

git submodule init
git submodule update

Let's update the test script above with a helpful hint on how to get nodeunit, if it's missing:

#!/usr/bin/env node
try {
    var reporter = require('nodeunit').reporters.default;
}
catch(e) {
    console.log("Cannot find nodeunit module.");
    console.log("You can download submodules for this project by doing:");
    console.log("");
    console.log("    git submodule init");
    console.log("    git submodule update");
    console.log("");
    process.exit();
}

process.chdir(__dirname);
reporter.run(['test']);

Now if someone attempts to run your test suite without nodeunit installed they will be prompted to download the submodules for your project.

Built-in Test Reporters

  • default - The standard reporter seen in the nodeunit screenshots
  • minimal - Pretty, minimal output, shows errors and progress only
  • html - Outputs a HTML report to stdout
  • junit - Creates jUnit compatible XML reports, which can be used with continuous integration tools such as Hudson.
  • machineout - Simple reporter for machine analysis. There is nodeunit.vim which is useful for TDD on VIM.

Writing a Test Reporter

Nodeunit exports runTest(fn, options), runModule(mod, options) and runFiles(paths, options). You'll most likely want to run test suites from files, which can be done using the latter function. The options argument can contain callbacks which run during testing. Nodeunit provides the following callbacks:

  • moduleStart(name) - called before a module is tested
  • moduleDone(name, assertions) - called once all test functions within the module have completed (see assertions object reference below) ALL tests within the module
  • testStart(name) - called before a test function is run
  • testReady(test) - called before a test function is run with the test object that will be passed to the test function
  • testDone(name, assertions) - called once a test function has completed (by calling test.done())
  • log(assertion) - called whenever an assertion is made (see assertion object reference below)
  • done(assertions) - called after all tests/modules are complete

The assertion object:

  • passed() - did the assertion pass?
  • failed() - did the assertion fail?
  • error - the AssertionError if the assertion failed
  • method - the nodeunit assertion method used (ok, same, equals...)
  • message - the message the assertion method was called with (optional)

The assertionList object:

  • An array-like object with the following new attributes:
    • failures() - the number of assertions which failed
    • duration - the time taken for the test to complete in msecs

For a reference implementation of a test reporter, see lib/reporters/default.js in the nodeunit project directory.

Sandbox utility

This is a function which evaluates JavaScript files in a sandbox and returns the context. The sandbox function can be used for testing client-side code or private un-exported functions within a module.

var sandbox = require('nodeunit').utils.sandbox;
var example = sandbox('example.js');

sandbox(files, sandbox) - Evaluates JavaScript files in a sandbox, returning the context. The first argument can either be a single filename or an array of filenames. If multiple filenames are given their contents are concatenated before evaluation. The second argument is an optional context to use for the sandbox.

Note: When working with the sandbox if your script depends on outside sources (i.e. using require) then you will want to pass that into the optional context when setting up the sandbox.

var sandbox = require('nodeunit').utils.sandbox;
// pass in some node globals
var box_globals = {
    // Passing module.exports into the sandbox will give your code  access to it.
    module: {exports: exports},
    // Passing require into the sandbox will give your code  access to use it AND
    // will share the cache with modules already required from outside the sandbox.
    require: require,
    // Passing console into the sandbox will give your code access to it
    console: console
};
var example = sandbox('example.js', box_globals);

Running the nodeunit Tests

The tests for nodeunit are written using nodeunit itself as the test framework. However, the module test-base.js first does some basic tests using the assert module to ensure that test functions are actually run, and a basic level of nodeunit functionality is available.

To run the nodeunit tests do:

make test

Note: There was a bug in node v0.2.0 causing the tests to hang, upgrading to v0.2.1 fixes this.

machineout reporter

The default reporter is readable for human but not for machine analysis. When you want to analyze the output of nodeunit, use machineout reporter and you will get

nodeunit with vim

There is nodeunit.vim so you can use nodeunit with VIM.

That compiler uses machineout reporter and it is useful to use with vim-makegreen.

Contributing

Contributions to the project are most welcome, so feel free to fork and improve. When submitting a pull request, please run make lint first to ensure we're following a consistent coding style.

nodeunit's People

Contributors

aeisenberg avatar alanshaw avatar alexgorbatchev avatar alexkwolfe avatar allanmboyd avatar azatoth avatar ben-pushspring avatar brettz9 avatar bryandonovan avatar cortesi avatar deitch avatar gerad avatar glenjamin avatar hugosenari avatar kadirpekel avatar lambdalisue avatar mattfenwick avatar mmalecki avatar mreinstein avatar mscdex avatar nicjansma avatar nycdotnet avatar perry-mitchell avatar rsternagel avatar sannis avatar soswow avatar sstephenson avatar teknopaul avatar tmpvar avatar toots avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

nodeunit's Issues

installing nodeunit with npm fails unless run by superuser

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

require.paths removed in node 0.5.2

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)

Feature: exit nodeunit on first failed test

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

testing http and extending nodeunit

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

Run object instead of runFiles?

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.

Parallel options

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

Ideas for implementation

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.

Add gh-pages branch with documentation

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

Should 'nodeunit directory_name' recurse through subdirectories?

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?

Better (or even the best?) browser support for Nodeunit!

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?

Unordered deepEquality for Arrays

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.

Not readable sign for "success" and "error" in windows console

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

cannot dynamically add named tests

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.

require('nodeunit') fails after npm install?

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?

Return nonzero exit status code in case of a test failure

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)

Redirecting reporter output to file

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.

Tests hang on master

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>

How to know when all tests (or all in a testCase) are done

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() {... }
})
});

Stacktrace improvements

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

Add test.throws() and test.doesNotThrow()

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.

npm update

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.

Group naming

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.

jscoverage support

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.

Adding include paths to CLI testrunner

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 with npm FAIL

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

Test runner dies when test.done() isn't called

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()?

Data Providers

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.

current npm version of nodeunit does not respond any

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.

Curious non-exiting behaviour when running with reporting output

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$

Asserts not counted by reporter

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

deepEqual() fails when testing objects with valueOf() equality

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)
> 

expect() might be redundant?

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?

Test with nodeunit 0.5.3 hangs used to work with 0.5.1

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');
    });
};

Why Explict Invocation of Callback is Needed in setUp and tearDown?

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

Can I run only one method in a testcase?

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

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.