Socket
Socket
Sign inDemoInstall

tap

Package Overview
Dependencies
Maintainers
1
Versions
418
Alerts
File Explorer

Advanced tools

Socket logo

Install Socket

Detect and block malicious and high-risk dependencies

Install

tap - npm Package Compare versions

Comparing version 16.3.8 to 18.5.8

dist/commonjs/dummy-import.d.ts

181

package.json
{
"name": "tap",
"version": "16.3.8",
"author": "Isaac Z. Schlueter <i@izs.me> (http://blog.izs.me)",
"version": "18.5.8",
"description": "A Test-Anything-Protocol library for JavaScript",
"homepage": "http://www.node-tap.org/",
"tshy": {
"main": true,
"exports": {
"./package.json": "./package.json",
".": "./src/index.ts"
}
},
"type": "module",
"bin": {
"tap": "bin/run.js"
"tap": "dist/esm/run.mjs"
},
"main": "lib/tap.js",
"main": "./dist/commonjs/index.js",
"types": "./dist/commonjs/index.d.ts",
"exports": {
"./package.json": "./package.json",
".": {
"import": "./lib/tap.mjs",
"default": "./lib/tap.js"
},
"./*": "./*",
"./mocha": "./lib/mocha.js"
"import": {
"types": "./dist/esm/index.d.ts",
"default": "./dist/esm/index.js"
},
"require": {
"types": "./dist/commonjs/index.d.ts",
"default": "./dist/commonjs/index.js"
}
}
},
"engines": {
"node": ">=12"
"files": [
"dist"
],
"scripts": {
"prepare": "tshy",
"pretest": "npm run prepare",
"presnap": "npm run prepare",
"test": "tap",
"snap": "tap",
"format": "prettier --write . --loglevel warn --ignore-path ../../.prettierignore --cache",
"typedoc": "typedoc --tsconfig tsconfig/esm.json ./src/*.ts"
},
"author": "Isaac Z. Schlueter <i@izs.me> (https://blog.izs.me)",
"license": "BlueOak-1.0.0",
"dependencies": {
"@isaacs/import-jsx": "^4.0.1",
"@types/react": "^17.0.52",
"chokidar": "^3.3.0",
"findit": "^2.0.0",
"foreground-child": "^2.0.0",
"fs-exists-cached": "^1.0.0",
"glob": "^7.2.3",
"ink": "^3.2.0",
"isexe": "^2.0.0",
"istanbul-lib-processinfo": "^2.0.3",
"jackspeak": "^1.4.2",
"libtap": "^1.4.0",
"minipass": "^3.3.4",
"mkdirp": "^1.0.4",
"nyc": "^15.1.0",
"opener": "^1.5.1",
"react": "^17.0.2",
"rimraf": "^3.0.0",
"signal-exit": "^3.0.6",
"source-map-support": "^0.5.16",
"tap-mocha-reporter": "^5.0.3",
"tap-parser": "^11.0.2",
"tap-yaml": "^1.0.2",
"tcompare": "^5.0.7",
"treport": "^3.0.4",
"which": "^2.0.2"
"@tapjs/after": "1.1.16",
"@tapjs/after-each": "1.1.16",
"@tapjs/asserts": "1.1.16",
"@tapjs/before": "1.1.16",
"@tapjs/before-each": "1.1.16",
"@tapjs/core": "1.4.5",
"@tapjs/filter": "1.2.16",
"@tapjs/fixture": "1.2.16",
"@tapjs/intercept": "1.2.16",
"@tapjs/mock": "1.2.14",
"@tapjs/node-serialize": "1.2.5",
"@tapjs/run": "1.4.15",
"@tapjs/snapshot": "1.2.16",
"@tapjs/spawn": "1.1.16",
"@tapjs/stdin": "1.1.16",
"@tapjs/test": "1.3.16",
"@tapjs/typescript": "1.3.5",
"@tapjs/worker": "1.1.16",
"resolve-import": "^1.4.5"
},
"devDependencies": {
"coveralls": "^3.1.1",
"eslint": "^7.32.0",
"flow-remove-types": "^2.193.0",
"node-preload": "^0.2.1",
"process-on-spawn": "^1.0.0",
"ts-node": "^8.5.2",
"typescript": "^3.7.2"
"tap": {
"typecheck": false,
"coverage-map": "map.js"
},
"peerDependencies": {
"coveralls": "^3.1.1",
"flow-remove-types": ">=2.112.0",
"ts-node": ">=8.5.2",
"typescript": ">=3.7.2"
"homepage": "http://www.node-tap.org/",
"engines": {
"node": "16 >=16.17.0 || 18 >= 18.6.0 || >=20"
},
"peerDependenciesMeta": {
"coveralls": {
"optional": true
},
"flow-remove-types": {
"optional": true
},
"ts-node": {
"optional": true
},
"typescript": {
"optional": true
}
},
"keywords": [

@@ -83,53 +78,15 @@ "assert",

"test",
"testing"
"testing",
"framework",
"cli",
"tapjs",
"tapjs plugin"
],
"license": "ISC",
"repository": "https://github.com/tapjs/node-tap.git",
"scripts": {
"snap": "node bin/run.js -M coverage-map.js",
"test": "node bin/run.js -M coverage-map.js",
"unit": "bash scripts/unit.sh",
"posttest": "rm -rf cli-tests-*",
"postsnap": "npm run lint:fix",
"postunit": "npm run posttest",
"t": "node bin/run.js -J -sfails.txt",
"preversion": "npm test",
"postversion": "npm publish",
"postpublish": "bash postpublish.sh",
"www:build": "cd docs; npm ci; npm run build",
"www:develop": "cd docs; npm run develop",
"start": "npm run www:develop",
"www:serve": "cd docs; npm run serve",
"lint": "eslint 'bin/*.js' 'lib/*.js' 'test/**/*.js'",
"lint:fix": "npm run lint -- --fix"
},
"tap": {
"test-regex": "^test/.*\\.js$",
"check-coverage": true
},
"nyc": {
"include": [
"bin/run.js",
"bin/jsx.js",
"lib/*.js",
"bin/jack.js"
]
},
"files": [
"settings.js",
"bin/run.js",
"bin/jsx.js",
"bin/jack.js",
"lib"
],
"bundleDependencies": [
"ink",
"treport",
"@types/react",
"@isaacs/import-jsx",
"react"
],
"funding": {
"url": "https://github.com/sponsors/isaacs"
},
"repository": {
"type": "git",
"url": "git+https://github.com/tapjs/tapjs.git"
}
}
# node-tap
A <abbr title="Test Anything Protocol">TAP</abbr> test framework for
Node.js.
A <abbr title="Test Anything Protocol">TAP</abbr> test framework
for Node.js.
![Build Status](https://github.com/tapjs/node-tap/workflows/ci/badge.svg)
_Just wanna see some code? [Get
started!](http://www.node-tap.org/basics/)_
_Just wanna see some code? [Get started!](http://www.node-tap.org/basics/)_
It includes a command line test runner for consuming
TAP-generating test scripts, and a JavaScript framework for
writing such scripts.
It includes a command line test runner for consuming TAP-generating test
scripts, and a JavaScript framework for writing such scripts.
<!-- TODO: update with new website docs links -->
* [Getting started guide](http://www.node-tap.org/basics/)
* Built-in [test coverage](http://www.node-tap.org/coverage/)
* Many [reporter formats](http://www.node-tap.org/reporting/)
* Extensive [API](http://www.node-tap.org/api/) featuring:
* Great [promise support](http://www.node-tap.org/promises/)
* Comprehensive [assert library](http://www.node-tap.org/asserts/)
* Other [advanced stuff](http://www.node-tap.org/advanced/)
* Mocha-like [BDD DSL](http://www.node-tap.org/mochalike/)
* [Parallel Testing](http://www.node-tap.org/parallel/)
* [Command-line interface](http://www.node-tap.org/cli/) for running tests
(whether they use node-tap or not)
- [Getting started guide](http://node-tap.org/basics/)
- Built-in [test coverage](http://node-tap.org/coverage/)
- Many [reporter formats](http://node-tap.org/reporter/)
- Extensive [API](http://node-tap.org/api/)
- [Command-line interface](http://node-tap.org/cli/) for
running tests (whether they use node-tap or not)
- [Machine-generated API docs](https://tapjs.github.io/tapjs)
See [the changelog](http://www.node-tap.org/changelog/) for recent updates,
or just get started with [the basics](http://www.node-tap.org/basics/).
See [the changelog](http://node-tap.org/changelog/) for recent
updates, or just get started with [the
basics](http://www.node-tap.org/basics/).
All this is too much to manage in a single README file, so head over to
[the website](http://www.node-tap.org/) to learn more.
All this is too much to manage in a single README file, so head
over to [the website](http://node-tap.org/) to learn more.
## Why TAP?
Why should you use this thing!? **LET ME TELL YOU!**
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.
Most frameworks spend a lot of their documentation telling you
why they're the greatest. This isn't that.
### <i lang="it" title="all tastes are tastes">tutti i gusti sono gusti</i>
Software testing is a software and user experience design challenge that
balances on the intersection of many conflicting demands.
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](http://izs.me) 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.
Node-tap is based on [my](http://izs.me) 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.**
Here are the design principles that shape this test framework.
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.
### Test files are "normal" programs
2. **Test output should be connected to the structure of the test file in a
way that is easy to determine.**
Any TAP test can be run directly as a plain old JavaScript
program. Of course, if it's written in TypeScript, you'll
have to run it with a TypeScript loader, but otherwise, they
should be just like normal programs that run in a normal
environment.
That means not unnecessarily deferring test functions until `nextTick`,
because that would shift the order of `console.log` output. Synchronous
tests should be synchronous.
But there's no runner required to run tests, they don't
execute in a special simulated memory space with injected
globals, and so on. Because each test runs in its own process,
there's no chance of tests becoming dependent on one another's
leaked globals or causing other confusing situations.
3. **Test files should be run in separate processes.**
### Tests should help, not get in the way
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.
The goal of tests is to help you write code. They add reliability
to your program by adding a layer of "yes, this does what I think
it does". Whether you're doing strict Red-Green-Refactor style
TDD, or just finger-painting until it feels right and then
writing tests to verify what it actually does, writing the tests
should feel empowering and straightforward, _reducing_ cognitive
load rather than increasing it.
4. **Assertions should not normally throw (but throws MUST be handled
nicely).**
### All types must be accurate and complete
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.
This is simply not reasonable to do with a hand-edited type
definition in `.d.ts` file.
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.
TAP's exported types are built up from its set of plugins and
internal classes, assembled into the `Test` class that your test
programs interact with. When a plugin is added or removed, the
`t` in your editor can accurately tell you its new shape.
5. **Test reporting should be separate from the test process, included in
the framework, and enabled by default for humans.**
If you have to look at the docs too often, that's a bug in my
opinion. Lean into the beautiful power of code completion.
The [raw test output](https://www.node-tap.org/tap-format/) should be
machine-parseable and human-intelligible, and a separate process should
consume test output and turn it into a [pretty summarized
report](https://www.node-tap.org/reporting/). This means that test data
can be stored and parsed later, dug into for additional details, and so
on. Also: nyan cat.
### TypeScript, ESM, and CommonJS supported out of the box
6. **Writing tests should be easy, maybe even fun.**
With the changes to the module system in Node.js over the
last several years, TAP fell down on this requirement in
versions prior to v18. As of version 18, the entire system has
been rewritten in TypeScript, and built as hybrid ESM/CommonJS
packages.
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.
Your tests should be written just like your program, with as few
barriers as possible. If you can do it in CommonJS, you can do it
in ESM, and vice versa (at least as far as TAP is concerned).
Whatever is in your `tsconfig.json` or `package.json`, it should
Just Work.
That being said, if you return 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.
### Anything that _can_ be a plugin _is_ a plugin
7. **Tests should output enough data to diagnose a failure, and no more or
less.**
The plugin system is leveraged for anything that does not
absolutely need to be included in the core.
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.
Basic [TAP](https://testanything.org) generation and flow
control, error handling, config loading, process management and
so on, are all included in the core. But TypeScript support,
mocking, almost all assertion methods, method and property
interception and spying, spawning/forking subtests, creating
fixtures, snapshots, and attaching lifecycle methods (among
others) are all relegated to plugins.
8. **Test coverage should be included.**
This means that features can be switched on or off or extended
very easily.
Running tests with coverage changes the way that you think about your
programs, and provides much deeper insight. Node-tap bundles
[NYC](https://istanbul.js.org/) for this.
### Plugins must be powerful and trivial to write correctly
It _does_ necessarily change the nature of the environment a little bit.
But in this case, it's worth it, and NYC has come a long way towards
maintaining this promise.
The plugin interface is extremely simple. Export a `plugin`
function that returns an object. That's it, that's a plugin.
Coverage _enforcement_ is not on by default, but I strongly encourage
it. You can put `"tap":{"check-coverage":true}` in your package.json,
or pass [`--100`](https://www.node-tap.org/100/) on the command line.
In a future version, it will likely be enabled by default.
Plugins can also export configuration definitions, which are
folded into the set of fields that TAP knows how to parse from
the command line or from your `.taprc` file, or export a `loader`
string, which will be invoked when spawning test processes.
9. **Tests should not require more building than your code.**
### High Signal, Low Noise
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](https://www.node-tap.org/promises/). JSX, TypeScript,
Flow, and ES-Modules are
[built-in](https://www.node-tap.org/using-with/) when tests are run by
the tap CLI.
It is important to give a lot of information about test failures,
throws, and so on, so that you can easily jump straight to the
appropriate place in the code to fix the problem. And, it's
usually helpful to see which tests are actually running.
10. **Tests should run as fast as possible, given all the prior
considerations.**
However, a screen full of green checkmarks and `100% Covered!`
isn't very useful. It should be just enough to know what happened
and easily diagnose any problems, and otherwise fairly quiet.
As of version 10, tap supports [parallel
tests](https://www.node-tap.org/parallel/). As of version 13, the test
runner defaults to running the same number of parallel tests as there
are CPUs on the system.
Low information output has been trimmed down as much as possible
from the default reporters. Coverage information is only shown
when it has something relevant to say. TAP tries to show you
exactly what you need to see, and nothing else. Stack traces have
noisy internals trimmed out, so it's easier to see exactly where
in _your_ code the problem happened. Source maps are always
enabled, because you need to know where the actual code is, not
just which built artifact failed.
This makes tests significantly faster in almost every case, on any machine
with multiple cores.
If the default reporter isn't terse enough for your liking, try
`tap -Rterse`.
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.
### Assertions don't throw (but throws are handled nicely)
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](https://www.node-tap.org/basics/).
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.
### Test reporting should be useful, extensible, and accessible
The [raw test output](https://www.node-tap.org/tap-format/)
is machine-parseable and human-intelligible, a separate component
consumes test output and turns it into a [pretty summarized
report](https://www.node-tap.org/reporting/). This means that
test data can be stored and parsed later, dug into for additional
details, and so on.
Red and green are the conventional colors meaning "removed" and
"added", but they're also exactly the same color for many people.
All of the color choices in the reporter are tested rigorously
against simulators for protanopia, deuteranopia, tritanopia, and
monochromicity.
### Test coverage is always on
Running tests with coverage changes the way that you think
about your programs, and provides much deeper insight.
TAP uses V8's internal coverage mechanisms directly, and verifies
that tests provide 100% coverage of all lines, branches,
functions, and statements in the system under test. It uses
[C8](https://npmjs.com/c8) to analyze the V8 coverage data and
generate coverage reports.
Missing coverage means that you are relying on untested code, so
this is treated as a test failure. If you have some bit of code
which is actually _impossible_ to test for some reason, wrap it
in the appropriate `/* c8 ignore start */` / `/* c8 ignore end
*/` comments to exclude those lines from the analysis. But think
carefully about whether that's really the case. Usually, if you
have to coverage-ignore something, it's a sign that you need to
either delete that code or refactor it into a more easily tested
module.
---
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. It should be
fun, because making stuff is fun, and it helps you make better
stuff.
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](https://www.node-tap.org/basics/).
SocketSocket SOC 2 Logo

Product

  • Package Alerts
  • Integrations
  • Docs
  • Pricing
  • FAQ
  • Roadmap
  • Changelog

Packages

npm

Stay in touch

Get open source security insights delivered straight into your inbox.


  • Terms
  • Privacy
  • Security

Made with ⚡️ by Socket Inc