What is tap?
The 'tap' npm package is a Test Anything Protocol (TAP) producer for Node.js. It is used for writing tests in JavaScript and provides a simple way to create and run tests, generate reports, and handle assertions.
What are tap's main functionalities?
Basic Test Creation
This feature allows you to create basic tests using the 'tap' module. The example demonstrates a simple test that checks if 1 + 1 equals 2.
const tap = require('tap');
tap.test('basic test', t => {
t.equal(1 + 1, 2, '1 + 1 should equal 2');
t.end();
});
Asynchronous Testing
This feature allows you to write asynchronous tests. The example shows how to use async/await to handle asynchronous operations within a test.
const tap = require('tap');
tap.test('async test', async t => {
const result = await new Promise(resolve => setTimeout(() => resolve(42), 100));
t.equal(result, 42, 'result should be 42');
t.end();
});
Nested Tests
This feature allows you to create nested tests. The example demonstrates a parent test containing a child test, which helps in organizing tests hierarchically.
const tap = require('tap');
tap.test('parent test', t => {
t.test('child test', t => {
t.equal(2 * 2, 4, '2 * 2 should equal 4');
t.end();
});
t.end();
});
Assertions
This feature provides various assertion methods to validate test conditions. The example shows different types of assertions like ok, notOk, equal, and notEqual.
const tap = require('tap');
tap.test('assertions test', t => {
t.ok(true, 'this should be true');
t.notOk(false, 'this should be false');
t.equal(3, 3, '3 should equal 3');
t.notEqual(3, 4, '3 should not equal 4');
t.end();
});
Other packages similar to tap
mocha
Mocha is a feature-rich JavaScript test framework running on Node.js and in the browser, making asynchronous testing simple and fun. It provides a variety of interfaces (BDD, TDD, etc.) and supports a wide range of reporters. Compared to 'tap', Mocha is more flexible and has a larger community.
jest
Jest is a delightful JavaScript Testing Framework with a focus on simplicity. It works out of the box for most JavaScript projects and provides a rich API for assertions, mocking, and more. Jest is more opinionated and comes with built-in features like snapshot testing, which 'tap' does not offer.
ava
AVA is a test runner for Node.js with a concise API, detailed error output, and process isolation. It runs tests concurrently, which can lead to faster test execution. AVA's approach to concurrency and simplicity makes it different from 'tap', which runs tests sequentially by default.
node-tap
A TAP test framework for
Node.js.
![Build Status](https://github.com/tapjs/node-tap/workflows/ci/badge.svg)
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.
-
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.
-
Test output should be connected to the structure of the test file in a
way 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.
-
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.
-
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.
-
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.
-
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 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.
-
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.
-
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 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.
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
on the command line.
In a future version, it will likely be enabled by default.
-
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. JSX, TypeScript,
Flow, and ES-Modules are
built-in when tests are run by
the tap CLI.
-
Tests should run as fast as possible, given all the prior
considerations.
As of version 10, tap supports parallel
tests. As of version 13, the test
runner defaults to running the same number of parallel tests as there
are CPUs on the system.
This makes tests significantly faster in almost every case, on any machine
with multiple cores.
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.