QUnit: the jQuery-era test framework still shipping a Node CLI

What the README claims, and what the manifest says instead

The README is short and confident. QUnit is described as a powerful, easy-to-use JavaScript testing framework, originally developed for the jQuery project and since evolved to test any client-side or server-side JavaScript code. It has no dependencies, and it supports all major desktop and mobile web browsers, Node.js and SpiderMonkey.

The package manifest in the same repository says something more complicated. Runtime dependencies are declared: commander at 12.1.0, node-watch at 0.7.4 and tiny-glob at 0.2.9. These are not exotic packages, but they are real entries in the dependency tree of anything installing QUnit.

They belong to the command line runner rather than the assertion library, which is the likely resolution of the contradiction. A framework whose core has no dependencies can still ship a CLI that watches files and expands globs. But the README's blanket claim is not literally true of the published package, and anyone auditing a dependency tree for a browser bundle will want to know which half they are looking at.

The repository tree supports that reading. `src/` holds the sources, `lib/` holds built output, `bin/` holds the executable, and `build/` is separate again.

A browser library and a Node executable from one package

The exports map is the part of package.json that tells you how the two delivery shapes work. The main entry is `qunit/qunit.js`, and the exports field branches by environment: under node there is an ESM wrapper at `./qunit/esm/qunit-wrapper-nodejs-module.js`, under module a CommonJS wrapper at `./qunit/esm/qunit-wrapper-bundler-require.js`, and a separate ESM build at `./qunit/esm/qunit.module.js`. A stylesheet is exported separately as `./qunit/qunit.css`, which is the styling for the HTML reporter that browsers run.

The command line side is declared through the bin field, which maps the executable name `qunit` to `bin/qunit.js`. The floor for running it comes from the engines field, which requires Node 18 or newer.

So the package is two products that happen to share a version number. The browser half is what test authors call, and the Node half is what a continuous integration job runs. Because commander parses arguments and node-watch watches the filesystem, the CLI is built for a local watch loop as much as for a one-shot run.

A comparison point worth naming: Jest and Vitest bundle their own runners, watchers and coverage instrumentation, and they assume a bundler or a transform pipeline. QUnit assumes neither. Its files are plain JavaScript you can drop into a page and open in a browser.

Version 3.0.0-rc1 on the branch while 2.26.0 shipped later

Here is a concrete versioning signal. The version field in package.json on the default branch reads 3.0.0-rc1. The release history shows 3.0.0-rc1 published on 2026-01-11, 2.25.0 on 2026-01-01 and 2.26.0 on 2026-06-01. The newest published release is therefore a 2.x, published roughly five months after the 3.0 release candidate.

That ordering has a practical consequence. The default branch carries a manifest that reports a pre-release version, so building from main does not give you what most people get from a package registry. If you want a stable line, 2.26.0 is the newest published release, and the 3.x line is still a candidate.

It also suggests the project is comfortable running two lines in parallel, which fits a framework whose consumers include large browser applications that cannot all upgrade at once. For a team picking QUnit today, the decision is between pinning the newest stable 2.x or accepting a release candidate in exchange for whatever changed in 3.0.

Release process documentation exists in the tree, in `RELEASE.md`, and version history sits in `History.md`. Neither file is referenced from the README, so release policy is something you read in the repository rather than on the project page.

Comparing QUnit with Jest, Vitest and Mocha

QUnit's design position is now dated in a way that is worth stating plainly. It is an assertion library plus a reporter, and it leaves the surrounding machinery to you.

Mocha stopped in a similar place: a runner with no assertions of its own, leaving assertion libraries to the user. QUnit bundles its own assertions and its own tap style output, so a QUnit test file is self-contained. Jest and Vitest went the other way, folding fixture files, mocking, snapshot files and coverage configuration into the default experience.

The cost of QUnit's narrower position is that the pieces modern runners treat as standard have to be sourced elsewhere. The tap keyword in the package metadata is there for interoperability with TAP output consumers rather than as evidence of a fixture system.

What you get in return is small and durable. No dependencies in the core, no transform step, a single file that runs in a page and on the server, and support for SpiderMonkey, which no mainstream runner bothers with. For a browser-first project where a browser is the actual target environment rather than a simulation of one, that last point has real value.

The README also links a browser automation page and a browser support page on qunitjs.com, plus a tested-with badge. Coverage runs through coveralls, with a coverage badge in the README.

A test framework that tests itself, and how it builds

The tree shows a framework with real infrastructure behind it. `Gruntfile.js` and `rollup.config.js` sit at the root, so there are two generations of build configuration rather than one current one. `.eslintrc.base.js` and `.eslintrc.json` indicate a split between a shared config and a project override. `.github/` holds the workflows, and the README badges point at continuous integration, reproducible builds, OpenSSF Best Practices and coveralls coverage.

That reproducible build badge is unusual for a testing library and says something about how the project treats its published artifacts. The browser test runner appears as a dev dependency, `@qunitjs/browserstack-runner`, which is how a framework claiming all major desktop and mobile browsers checks that claim.

The development dependencies show age and discipline at once. `benchmark` tracks performance, Babel with preset-env handles transpilation, and `eslint-config-semistandard` ties lint style to community rules rather than an in-house config.

Governance is written down rather than assumed. `AUTHORS.txt` credits contributors, `CONTRIBUTING.md` is the contribution guide, `SECURITY.md` covers reporting vulnerabilities and `CODE_OF_CONDUCT.md` the conduct policy. The package author field credits the OpenJS Foundation and other contributors, which places the project inside a foundation rather than one company's toolchain.

What the documentation does and does not settle

The README is a pointer document. It links API documentation, guides, browser support information and browser automation integrations, all on qunitjs.com. Nothing in it shows a test file, a command or an install step, so a reader who wants to run QUnit today has to leave the repository page.

That gap has an upside. For a framework whose premise is that you can include a script and open a page, documentation by example is the documentation. The API pages carry the assertion vocabulary and the guides carry the patterns.

For Node users the repository is more useful than the README suggests, because the manifest documents the contract: Node 18 or newer, a `qunit` executable at `bin/qunit.js`, ESM and CommonJS entry points, and a CSS export for the browser reporter. Those four facts are enough to reason about integration without guessing.

What remains unsettled is the 3.0 transition. The README does not mention it, the branch already carries the candidate version, and the newest published release is still 2.26.0. Anyone planning a migration needs the release notes and the API documentation rather than the repository landing page.

Editorial conclusion

QUnit earns its place in a codebase that already has jQuery lineage, wants tests that run unchanged in a browser and on the server, and does not want a compiler in the loop. It is a poor fit if you want fixtures, watch mode and mocking bundled in, or if you want a 3.x line today rather than a release candidate. The first thing to verify is which version you would actually install: the manifest on the default branch reports 3.0.0-rc1 while 2.26.0 is the most recent published release. Second, read the bin and engines fields in package.json, because that file, not the README, describes what the tool needs to run.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. qunitjs/qunit on GitHub
4. README
5. Releases