tap 10.3.2

A Test-Anything-Protocol library

Homepage: http://node-tap.org/

Platform: npm

Language: JavaScript

License: ISC

Keywords: assert, test, tap

Repository: git+https://github.com/tapjs/node-tap.git

View on registry: https://www.npmjs.com/package/tap

Direct download link: https://registry.npmjs.org/tap/-/tap-10.3.2.tgz

Install: npm install [email protected]


A TAP test framework for Node.js.

Build Status Build Status Coverage Status

Just wanna see some code? Get started!

It includes a command line test runner for consuming TAP-generating test scripts, and a JavaScript framework for writing such scripts.

See the changelog for recent updates, or just get started with the basics.

All this is too much to manage in a single README file, so head over to the website to learn more.

Why TAP?

Why should you use this thing!? LET ME TELL YOU!

Just kidding.

Most frameworks spend a lot of their documentation telling you why they're the greatest. I'm not going to do that.

tutti i gusti, sono gusti

Software testing is a software and user experience design challenge that balances on the intersection of many conflicting demands.

Node-tap is based on my opinions about how a test framework should work, and what it should let you do. I do not have any opinion about whether or not you share those opinions. If you do share them, you will probably enjoy this test library.

  1. Test files should be "normal" programs that can be run directly.

    That means that it can't require a special runner that puts magic functions into a global space. node test.js is a perfectly ok way to run a test, and it ought to function exactly the same as when it's run by the fancy runner with reporting and such. JavaScript tests should be JavaScript programs; not english-language poems with weird punctuation.

  2. Test output should be connected to the structure of the test file that is easy to determine.

    That means not unnecessarily deferring test functions until nextTick, because that would shift the order of console.log output. Synchronous tests should be synchronous.

  3. Test files should be run in separate processes.

    That means that it can't use require() to load test files. Doing node ./test.js must be the exact same sort of environment for the test as doing test-runner ./test.js. Doing node test/1.js; node test/2.js should be equivalent (from the test's point of view) to doing test-runner test/*.js. This prevents tests from becoming implicitly dependent on one anothers' globals.

  4. Assertions should not normally throw (but throws MUST be handled nicely).

    I frequently write programs that have many hundreds of assertions based on some list of test cases. If the first failure throws, then I don't know if I've failed 100 tests or 1, without wrapping everything in a try-catch. Furthermore, I usually want to see some kind of output or reporting to verify that each one actually ran.

    Basically, it should be your decision whether you want to throw or not. The test framework shouldn't force that on you, and should make either case easy.

  5. Test reporting should be separate from the test process, included in the framework, and enabled by default for humans.

    The raw test output should be machine-parseable and human-intelligible, and a separate process should consume test output and turn it into a pretty summarized report. This means that test data can be stored and parsed later, dug into for additional details, and so on. Also: nyan cat.

  6. Writing tests should be easy, maybe even fun.

    The lower the barrier to entry for writing new tests, the more tests get written. That means that there should be a relatively small vocabulary of actions that I need to remember as a test author. There is no benefit to having a distinction between a "suite" and a "subtest". Fancy DSLs are pretty, but more to remember.

    That being said, if the you returns a Promise, or use a DSL that throws a decorated error, then the test framework should Just Work in a way that helps a human being understand the situation.

  7. Tests should output enough data to diagnose a failure, and no more or less.

    Stack traces pointing at JS internals or the guts of the test framework itself are not helpful. A test framework is a serious UX challenge, and should be treated with care.

  8. Test coverage should be included.

    Running tests with coverage changes the way that you think about your programs, and provides much deeper insight. Node-tap bundles nyc for this.

    It's not enabled by default only because it does necessarily change the nature of the environment a little bit. But I strongly encourage enabling coverage.

  9. Tests should be output in a predictable order.

    Even if they are run in parallel, the test output should be consistent.

    As of version 10, tap supports parallel tests, which can make your tests run significantly faster if they are I/O bound or if you have multiple cores on your machine. However, even when run in parallel, the output is still serialized.

  10. Tests should not require more building than your code.

    Babel and Webpack are lovely and fine. But if your code doesn't require compilation, then I think your tests shouldn't either. Tap is extremely promise-aware, but works on any version of Node.js back to v0.10.

Software testing should help you build software. It should be a security blanket and a quality ratchet, giving you the support to undertake massive refactoring and fix bugs without worrying. It shouldn't be a purification rite or a hazing ritual.

There are many opinions left off of this list! Reasonable people can disagree. But if you find yourself nodding along, maybe tap is for you.

Dependencies Requirements Latest Stable Latest Release Licenses
bind-obj-methods ^1.0.0 1.0.0 1.0.0 ISC
bluebird ^3.3.1 3.5.0 3.5.0 MIT
clean-yaml-object ^0.1.0 0.1.0 0.1.0 MIT
color-support ^1.1.0 1.1.2 1.1.2 ISC
coveralls ^2.11.2 2.13.0 2.13.0 BSD-2-Clause
deeper ^2.1.0 2.1.0 2.1.0 BSD-2-Clause
foreground-child ^1.3.3 1.5.6 1.5.6 ISC
fs-exists-cached ^1.0.0 1.0.0 1.0.0 ISC
function-loop ^1.0.1 1.0.1 1.0.1 ISC
glob ^7.0.0 7.1.1 7.1.1 ISC
isexe ^1.0.0 2.0.0 2.0.0 ISC
js-yaml ^3.3.1 3.8.3 3.8.3 MIT
nyc ^10.0.0 10.2.2 10.3.0-candidate.0 ISC
only-shallow ^1.0.2 1.2.0 1.2.0 ISC
opener ^1.4.1 1.4.3 1.4.3 MIT
os-homedir 1.0.1 1.0.2 1.0.2 MIT
own-or ^1.0.0 1.0.0 1.0.0 ISC
own-or-env ^1.0.0 1.0.0 1.0.0 ISC
readable-stream ^2.0.2 2.2.9 2.2.9 MIT
signal-exit ^3.0.0 3.0.2 3.0.2 ISC
source-map-support ^0.4.3 0.4.14 0.4.14 MIT
stack-utils ^1.0.0 1.0.1 1.0.1 MIT
tap-mocha-reporter ^3.0.1 3.0.3 3.0.3 ISC
tap-parser ^5.3.1 5.3.3 5.3.3 MIT
tmatch ^3.0.0 3.0.0 3.0.0 ISC
trivial-deferred ^1.0.1 1.0.1 1.0.1 ISC
yapool ^1.0.0 1.0.0 1.0.0 ISC
Explore the resolved dependency tree for tap 10.3.2
Development Dependencies Requirements Latest Stable Latest Release Licenses
mkdirp ^0.5.1 0.5.1 0.5.1 MIT
rimraf ^2.5.4 2.6.1 2.6.1 ISC
standard ^7.1.0 10.0.2 10.0.2 MIT
which ^1.1.1 1.2.14 1.2.14 ISC
Explore the resolved development dependency tree for tap 10.3.2


10.3.2 April 09, 2017
10.3.1 March 29, 2017
10.3.0 March 02, 2017
10.2.2 February 27, 2017
10.2.1 February 23, 2017
10.2.0 February 19, 2017
10.1.2 February 18, 2017
10.1.1 February 14, 2017
10.1.0 February 07, 2017
10.0.2 February 02, 2017
See all 142 releases

Project Statistics

SourceRank 25
Dependencies 27
Dependent projects 5.19K
Dependent repositories 10K
Total releases 142
Latest release
First release
Stars 1K
Forks 116
Watchers 25
Contributors 45
Repo Size: 1.63 MB

Top Contributors See all

isaacs Pedro Palazón Candel Ryan Graham James Halliday Jon Ege Ronnenberg Jason Smith James Talmage Benjamin E. Coe Simeon Vincent Trent Mick fscherwi Evan Lucas Jan Olaf Krems Jo Liss Stein Martin Hustad John Resig Tom MacWright Thorsten Lorenz Max Tobias Weber Forrest L Norvell

Something wrong with this page? Make a suggestion

Export .ABOUT file for this library

Last synced: 2017-04-21 14:08:52 UTC

Login to resync this project