Name: js-handler/node_modules/nodeunit/README.md 
1:
Nodeunit
2:
========
3:
 
4:
Simple syntax, powerful tools. Nodeunit provides easy async unit testing for
5:
node.js and the browser.
6:
 
7:
* Simple to use
8:
* Just export the tests from a module
9:
* Works with node.js and in the browser.
10:
* Helps you avoid common pitfalls when testing asynchronous code
11:
* Easy to add test cases with setUp and tearDown functions if you wish
12:
* Flexible reporters for custom output, built-in support for HTML and jUnit XML
13:
* Allows the use of mocks and stubs
14:
 
15:
__Contributors__
16:
 
17:
* [alexgorbatchev](https://github.com/alexgorbatchev)
18:
* [alexkwolfe](https://github.com/alexkwolfe)
19:
* [azatoth](https://github.com/azatoth)
20:
* [kadirpekel](https://github.com/kadirpekel)
21:
* [lambdalisue](https://github.com/lambdalisue)
22:
* [luebken](https://github.com/luebken)
23:
* [orlandov](https://github.com/orlandov)
24:
* [Sannis](https://github.com/Sannis)
25:
* [sstephenson](https://github.com/sstephenson)
26:
* [thegreatape](https://github.com/thegreatape)
27:
* [mmalecki](https://github.com/mmalecki)
28:
* and thanks to [cjohansen](https://github.com/cjohansen) for input and advice
29:
  on implementing setUp and tearDown functions. See
30:
  [cjohansen's fork](https://github.com/cjohansen/nodeunit).
31:
 
32:
Also, check out gerad's [nodeunit-dsl](https://github.com/gerad/nodeunit-dsl)
33:
project, which implements a 'pretty dsl on top of nodeunit'.
34:
 
35:
More contributor information can be found in the
36:
[CONTRIBUTORS.md](https://github.com/caolan/nodeunit/blob/master/CONTRIBUTORS.md)
37:
file.
38:
 
39:
Usage
40:
-----
41:
 
42:
Here is an example unit test module:
43:
 
44:
    exports.testSomething = function(test){
45:
        test.expect(1);
46:
        test.ok(true, "this assertion should pass");
47:
        test.done();
48:
    };
49:
 
50:
    exports.testSomethingElse = function(test){
51:
        test.ok(false, "this assertion should fail");
52:
        test.done();
53:
    };
54:
 
55:
When run using the included test runner, this will output the following:
56:
 
57:
<img src="https://github.com/caolan/nodeunit/raw/master/img/example_fail.png" />
58:
 
59:
Installation
60:
------------
61:
 
62:
There are two options for installing nodeunit:
63:
 
64:
1. Clone / download nodeunit from [github](https://github.com/caolan/nodeunit),
65:
   then:
66:
 
67:
    make && sudo make install
68:
 
69:
2. Install via npm:
70:
 
71:
    npm install nodeunit
72:
 
73:
API Documentation
74:
-----------------
75:
 
76:
Nodeunit uses the functions available in the node.js
77:
[assert module](http://nodejs.org/docs/v0.4.2/api/assert.html):
78:
 
79:
* __ok(value, [message])__ - Tests if value is a true value.
80:
* __equal(actual, expected, [message])__ - Tests shallow, coercive equality
81:
  with the equal comparison operator ( == ).
82:
* __notEqual(actual, expected, [message])__ - Tests shallow, coercive
83:
  non-equality with the not equal comparison operator ( != ).
84:
* __deepEqual(actual, expected, [message])__ - Tests for deep equality.
85:
* __notDeepEqual(actual, expected, [message])__ - Tests for any deep
86:
  inequality.
87:
* __strictEqual(actual, expected, [message])__ - Tests strict equality, as
88:
  determined by the strict equality operator ( === )
89:
* __notStrictEqual(actual, expected, [message])__ - Tests strict non-equality,
90:
  as determined by the strict not equal operator ( !== )
91:
* __throws(block, [error], [message])__ - Expects block to throw an error.
92:
* __doesNotThrow(block, [error], [message])__ - Expects block not to throw an
93:
  error.
94:
* __ifError(value)__ - Tests if value is not a false value, throws if it is a
95:
  true value. Useful when testing the first argument, error in callbacks.
96:
 
97:
Nodeunit also provides the following functions within tests:
98:
 
99:
* __expect(amount)__ - Specify how many assertions are expected to run within a
100:
  test. Very useful for ensuring that all your callbacks and assertions are
101:
  run.
102:
* __done()__ - Finish the current test function, and move on to the next. ALL
103:
  tests should call this!
104:
 
105:
Nodeunit aims to be simple and easy to learn. This is achieved through using
106:
existing structures (such as node.js modules) to maximum effect, and reducing
107:
the API where possible, to make it easier to digest.
108:
 
109:
Tests are simply exported from a module, but they are still run in the order
110:
they are defined.
111:
 
112:
__Note:__ Users of old nodeunit versions may remember using ok, equals and same
113:
in the style of qunit, instead of the assert functions above. These functions
114:
still exist for backwards compatibility, and are simply aliases to their assert
115:
module counterparts.
116:
 
117:
 
118:
Asynchronous Testing
119:
--------------------
120:
 
121:
When testing asynchronous code, there are a number of sharp edges to watch out
122:
for. Thankfully, nodeunit is designed to help you avoid as many of these
123:
pitfalls as possible. For the most part, testing asynchronous code in nodeunit
124:
_just works_.
125:
 
126:
 
127:
### Tests run in series
128:
 
129:
While running tests in parallel seems like a good idea for speeding up your
130:
test suite, in practice I've found it means writing much more complicated
131:
tests. Because of node's module cache, running tests in parallel means mocking
132:
and stubbing is pretty much impossible. One of the nicest things about testing
133:
in javascript is the ease of doing stubs:
134:
 
135:
    var _readFile = fs.readFile;
136:
    fs.readFile = function(path, callback){
137:
        // its a stub!
138:
    };
139:
    // test function that uses fs.readFile
140:
 
141:
    // we're done
142:
    fs.readFile = _readFile;
143:
 
144:
You cannot do this when running tests in parallel. In order to keep testing as
145:
simple as possible, nodeunit avoids it. Thankfully, most unit-test suites run
146:
fast anyway.
147:
 
148:
 
149:
### Explicit ending of tests
150:
 
151:
When testing async code its important that tests end at the correct point, not
152:
just after a given number of assertions. Otherwise your tests can run short,
153:
ending before all assertions have completed. Its important to detect too
154:
many assertions as well as too few. Combining explicit ending of tests with
155:
an expected number of assertions helps to avoid false test passes, so be sure
156:
to use the test.expect() method at the start of your test functions, and
157:
test.done() when finished.
158:
 
159:
 
160:
Groups, setUp and tearDown
161:
--------------------------
162:
 
163:
Nodeunit allows the nesting of test functions:
164:
 
165:
    exports.test1 = function (test) {
166:
        ...
167:
    }
168:
 
169:
    exports.group = {
170:
        test2: function (test) {
171:
            ...
172:
        },
173:
        test3: function (test) {
174:
            ...
175:
        }
176:
    }
177:
 
178:
This would be run as:
179:
 
180:
    test1
181:
    group - test2
182:
    group - test3
183:
 
184:
Using these groups, Nodeunit allows you to define a `setUp` function, which is
185:
run before each test, and a `tearDown` function, which is run after each test
186:
calls `test.done()`:
187:
 
188:
    module.exports = {
189:
        setUp: function (callback) {
190:
            this.foo = 'bar';
191:
            callback();
192:
        },
193:
        tearDown: function (callback) {
194:
            // clean up
195:
            callback();
196:
        },
197:
        test1: function (test) {
198:
            test.equals(this.foo, 'bar');
199:
            test.done();
200:
        }
201:
    };
202:
 
203:
In this way, its possible to have multiple groups of tests in a module, each
204:
group with its own setUp and tearDown functions.
205:
 
206:
 
207:
Running Tests
208:
-------------
209:
 
210:
Nodeunit comes with a basic command-line test runner, which can be installed
211:
using 'sudo make install'. Example usage:
212:
 
213:
    nodeunit testmodule1.js testfolder [...]
214:
 
215:
The default test reporter uses color output, because I think that's more fun :) I
216:
intend to add a no-color option in future. To give you a feeling of the fun you'll
217:
be having writing tests, lets fix the example at the start of the README:
218:
 
219:
<img src="https://github.com/caolan/nodeunit/raw/master/img/example_pass.png" />
220:
 
221:
Ahhh, Doesn't that feel better?
222:
 
223:
When using the included test runner, it will exit using the failed number of
224:
assertions as the exit code. Exiting with 0 when all tests pass.
225:
 
226:
 
227:
### Command-line Options
228:
 
229:
* __--reporter FILE__ - you can set the test reporter to a custom module or
230:
on of the modules in nodeunit/lib/reporters, when omitted, the default test runner
231:
is used.
232:
* __--list-reporters__ - list available build-in reporters.
233:
* __--config FILE__ - load config options from a JSON file, allows
234:
the customisation of color schemes for the default test reporter etc. See
235:
bin/nodeunit.json for current available options.
236:
* __--version__ or __-v__ - report nodeunit version
237:
* __--help__ - show nodeunit help
238:
 
239:
 
240:
Running tests in the browser
241:
----------------------------
242:
 
243:
Nodeunit tests can also be run inside the browser. For example usage, see
244:
the examples/browser folder. The basic syntax is as follows:
245:
 
246:
__test.html__
247:
 
248:
    <html>
249:
      <head>
250:
        <title>Example Test Suite</title>
251:
        <link rel="stylesheet" href="nodeunit.css" type="text/css" />
252:
        <script src="nodeunit.js"></script>
253:
        <script src="suite1.js"></script>
254:
        <script src="suite2.js"></script>
255:
      </head>
256:
      <body>
257:
        <h1 id="nodeunit-header">Example Test Suite</h1>
258:
        <script>
259:
          nodeunit.run({
260:
            'Suite One': suite1,
261:
            'Suite Two': suite2
262:
          });
263:
        </script>
264:
      </body>
265:
    </html>
266:
 
267:
Here, suite1 and suite2 are just object literals containing test functions or
268:
groups, as would be returned if you did require('test-suite') in node.js:
269:
 
270:
__suite1.js__
271:
 
272:
    this.suite1 = {
273:
        'example test': function (test) {
274:
            test.ok(true, 'everything is ok');
275:
            test.done();
276:
        }
277:
    };
278:
 
279:
If you wish to use a commonjs format for your test suites (using exports), it is
280:
up to you to define the commonjs tools for the browser. There are a number of
281:
alternatives and its important it fits with your existing code, which is
282:
why nodeunit does not currently provide this out of the box.
283:
 
284:
In the example above, the tests will run when the page is loaded.
285:
 
286:
The browser-version of nodeunit.js is created in dist/browser when you do, 'make
287:
browser'. You'll need [UglifyJS](https://github.com/mishoo/UglifyJS) installed in
288:
order for it to automatically create nodeunit.min.js.
289:
 
290:
 
291:
Adding nodeunit to Your Projects
292:
--------------------------------
293:
 
294:
If you don't want people to have to install the nodeunit command-line tool,
295:
you'll want to create a script that runs the tests for your project with the
296:
correct require paths set up. Here's an example test script, that assumes you
297:
have nodeunit in a suitably located node_modules directory.
298:
 
299:
    #!/usr/bin/env node
300:
    var reporter = require('nodeunit').reporters.default;
301:
    reporter.run(['test']);
302:
 
303:
If you're using git, you might find it useful to include nodeunit as a
304:
submodule. Using submodules makes it easy for developers to download nodeunit
305:
and run your test suite, without cluttering up your repository with
306:
the source code. To add nodeunit as a git submodule do the following:
307:
 
308:
    git submodule add git://github.com/caolan/nodeunit.git node_modules/nodeunit
309:
 
310:
This will add nodeunit to the node_modules folder of your project. Now, when
311:
cloning the repository, nodeunit can be downloaded by doing the following:
312:
 
313:
    git submodule init
314:
    git submodule update
315:
 
316:
Let's update the test script above with a helpful hint on how to get nodeunit,
317:
if its missing:
318:
 
319:
    #!/usr/bin/env node
320:
    try {
321:
        var reporter = require('nodeunit').reporters.default;
322:
    }
323:
    catch(e) {
324:
        console.log("Cannot find nodeunit module.");
325:
        console.log("You can download submodules for this project by doing:");
326:
        console.log("");
327:
        console.log("    git submodule init");
328:
        console.log("    git submodule update");
329:
        console.log("");
330:
        process.exit();
331:
    }
332:
 
333:
    process.chdir(__dirname);
334:
    reporter.run(['test']);
335:
 
336:
Now if someone attempts to run your test suite without nodeunit installed they
337:
will be prompted to download the submodules for your project.
338:
 
339:
 
340:
Built-in Test Reporters
341:
-----------------------
342:
 
343:
* __default__ - The standard reporter seen in the nodeunit screenshots
344:
* __minimal__ - Pretty, minimal output, shows errors and progress only
345:
* __html__ - Outputs a HTML report to stdout
346:
* __junit__ - Creates jUnit compatible XML reports, which can be used with
347:
  continuous integration tools such as [Hudson](http://hudson-ci.org/).
348:
* __machineout__ - Simple reporter for machine analysis. There is [nodeunit.vim](https://github.com/lambdalisue/nodeunit.vim)
349:
  which is useful for TDD on VIM
350:
 
351:
 
352:
Writing a Test Reporter
353:
---------------------
354:
 
355:
Nodeunit exports runTest(fn, options), runModule(mod, options) and
356:
runFiles(paths, options). You'll most likely want to run test suites from
357:
files, which can be done using the latter function. The _options_ argument can
358:
contain callbacks which run during testing. Nodeunit provides the following
359:
callbacks:
360:
 
361:
* __moduleStart(name)__ - called before a module is tested
362:
* __moduleDone(name, assertions)__ - called once all test functions within the
363:
  module have completed (see assertions object reference below)
364:
  ALL tests within the module
365:
* __testStart(name)__ - called before a test function is run
366:
* __testDone(name, assertions)__ - called once a test function has completed
367:
  (by calling test.done())
368:
* __log(assertion)__ - called whenever an assertion is made (see assertion
369:
  object reference below)
370:
* __done(assertions)__ - called after all tests/modules are complete
371:
 
372:
The __assertion__ object:
373:
 
374:
* __passed()__ - did the assertion pass?
375:
* __failed()__ - did the assertion fail?
376:
* __error__ - the AssertionError if the assertion failed
377:
* __method__ - the nodeunit assertion method used (ok, same, equals...)
378:
* __message__ - the message the assertion method was called with (optional)
379:
 
380:
The __assertionList__ object:
381:
 
382:
* An array-like object with the following new attributes:
383:
  * __failures()__ - the number of assertions which failed
384:
  * __duration__ - the time taken for the test to complete in msecs
385:
 
386:
For a reference implementation of a test reporter, see lib/reporters/default.js in
387:
the nodeunit project directory.
388:
 
389:
 
390:
Sandbox utility
391:
---------------
392:
 
393:
This is a function which evaluates JavaScript files in a sandbox and returns the
394:
context. The sandbox function can be used for testing client-side code or private
395:
un-exported functions within a module.
396:
 
397:
    var sandbox = require('nodeunit').utils.sandbox;
398:
    var example = sandbox('example.js');
399:
 
400:
__sandbox(files, sandbox)__ - Evaluates JavaScript files in a sandbox, returning
401:
the context. The first argument can either be a single filename or an array of
402:
filenames. If multiple filenames are given their contents are concatenated before
403:
evalution. The second argument is an optional context to use for the sandbox.
404:
 
405:
 
406:
Running the nodeunit Tests
407:
--------------------------
408:
 
409:
The tests for nodeunit are written using nodeunit itself as the test framework.
410:
However, the module test-base.js first does some basic tests using the assert
411:
module to ensure that test functions are actually run, and a basic level of
412:
nodeunit functionality is available.
413:
 
414:
To run the nodeunit tests do:
415:
 
416:
    make test
417:
 
418:
__Note:__ There was a bug in node v0.2.0 causing the tests to hang, upgrading
419:
to v0.2.1 fixes this.
420:
 
421:
 
422:
__machineout__ reporter
423:
----------------------------------------------
424:
 
425:
The default reporter is really readable for human but for machinally analysis.
426:
When you want to analyze the output of nodeunit, use __machineout__ reporter and you will get
427:
 
428:
<img src="https://github.com/caolan/nodeunit/raw/master/img/example_machineout.png" />
429:
 
430:
 
431:
nodeunit with vim
432:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
433:
There is [nodeunit.vim](https://github.com/lambdalisue/nodeunit.vim) so you can use nodeunit with VIM.
434:
That compiler use __machineout__ reporter and it is useful to use with [vim-makegreen](https://github.com/reinh/vim-makegreen)
435:
 
436:
    
437:
 
438:
Contributing
439:
------------
440:
 
441:
Contributions to the project are most welcome, so feel free to fork and improve.
442:
When submitting a pull request, please run 'make lint' first to ensure
443:
we're following a consistent coding style.