Security News
JSR Working Group Kicks Off with Ambitious Roadmap and Plans for Open Governance
At its inaugural meeting, the JSR Working Group outlined plans for an open governance model and a roadmap to enhance JavaScript package management.
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.
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();
});
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 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 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.
A TAP test framework for Node.js.
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 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. This isn't that.
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.
Here are the design principles that shape this test framework.
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.
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.
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.
This is simply not reasonable to do with a hand-edited type
definition in .d.ts
file.
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.
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.
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.
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.
The plugin system is leveraged for anything that does not absolutely need to be included in the core.
Basic TAP 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.
This means that features can be switched on or off or extended very easily.
The plugin interface is extremely simple. Export a plugin
function that returns an object. That's it, that's a plugin.
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.
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.
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.
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.
If the default reporter isn't terse enough for your liking, try
tap -Rterse
.
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.
The raw test output is machine-parseable and human-intelligible, a separate component consumes test output and turns 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.
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.
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 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.
FAQs
A Test-Anything-Protocol library for JavaScript
The npm package tap receives a total of 244,177 weekly downloads. As such, tap popularity was classified as popular.
We found that tap demonstrated a healthy version release cadence and project activity because the last version was released less than a year ago. It has 1 open source maintainer collaborating on the project.
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Security News
At its inaugural meeting, the JSR Working Group outlined plans for an open governance model and a roadmap to enhance JavaScript package management.
Security News
Research
An advanced npm supply chain attack is leveraging Ethereum smart contracts for decentralized, persistent malware control, evading traditional defenses.
Security News
Research
Attackers are impersonating Sindre Sorhus on npm with a fake 'chalk-node' package containing a malicious backdoor to compromise developers' projects.