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