# jasmine/jasmine: a BDD test framework that runs in Node and the browser

> Jasmine is a behavior driven development testing framework for JavaScript that does not depend on a DOM or another framework. It suits Node.js projects and browser test suites, but the README sends you to the documentation site for install steps, and the package on npm is jasmine-core.

**jasmine/jasmine** — Simple JavaScript testing framework for browsers and node.js

- Repository: https://github.com/jasmine/jasmine
- Website: http://jasmine.github.io/
- Stars: 15,813 · Forks: 2,235
- Language: JavaScript
- License: MIT
- Published: 2026-09-21 · Updated: 2026-09-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/jasmine-jasmine

## What jasmine/jasmine solves, and who it is for

Jasmine is a Behavior Driven Development testing framework for JavaScript. The README makes one claim that separates it from most of its neighbours: it does not rely on browsers, DOM, or any JavaScript framework. That sentence is the whole pitch. A spec written against the framework's global functions does not need a document object, a module loader, or a component runtime to execute, which is why the README says it is suited to websites, Node.js projects, or anywhere that JavaScript can run.

The audience follows from that. If you are testing pure functions, a small library, or code you want to exercise both in Node and in a real browser without maintaining two suites, the framework's shape fits. If your test needs a rendered component tree, a headless browser, or a DOM implementation, you supply that yourself; the framework does not ship one. The repository's own test script runs the specs in Node and then runs lint, which is a fair picture of the intended workflow: a Node process is the default home, and the browser is a supported second target rather than the centre of gravity.

## How specs, suites and matchers fit together

The unit of work is a spec, created by calling a global function with a description string and a function body. Specs are grouped into suites by wrapping them in a describe block, and nested describe blocks nest the suites. The framework collects these declarations, then executes them and reports which passed and which failed. The README points to the Your First Suite tutorial for writing specs, so the exact matcher list lives on the documentation site rather than in the repository README.

The design consequence is that the framework is a library plus a runner, not a plugin ecosystem. There is no adapter layer to configure for a specific module format, and no DOM to boot. That is also why the package you install is called jasmine-core: the repository's package.json sets the name to jasmine-core and points main at ./lib/jasmine-core.js. The published tarball is deliberately small. Its files field lists only LICENSE, README.md, the images directory, lib with JavaScript and CSS, and package.json. Nothing in that list is a CLI, so the command line tooling lives in a separate package, and the README's Installation section simply directs readers to the Getting Started page for the environment-specific options.

## Installing jasmine and running a first suite

The README does not print install commands. It says there are several ways to install Jasmine depending on your environment and links to the Getting Started page. What follows is drawn from the repository's own files rather than from the README.

The repository's package.json declares the jasmine package as a devDependency at ^7.0.0, and its test script is:

```json
"test": "node scripts/runSpecsInNode.js && npm run lint"
```

That script shows the default shape of a Jasmine run in this project: a Node entry point that loads the specs, followed by lint. The repository also ships a script that serves the suite to a browser:

```json
"serve": "node spec/support/localJasmineBrowser.js"
```

The repository's build script produces the distributed files that the published package contains:

```json
"build": "node scripts/buildDistribution.js"
```

For your own project, the README directs you to the Getting Started page for the install command that matches your environment, and to the Your First Suite tutorial for writing the first spec. The repository layout shows where that spec code lives here: a spec directory at the top level, alongside src. The package you depend on for the core is jasmine-core, whose main entry is ./lib/jasmine-core.js.

## The supported-environment table is narrower than it looks

The README publishes a table of environments the project tests itself against. Node is listed as 20, 22, 24 and 26, with 20 marked as supported on a best-effort basis. Safari is listed at 26, also best-effort. Chrome and Edge are evergreen. Firefox is evergreen plus 140.

The footnote is the part worth reading twice. For the best-effort versions, the README states that support may be dropped if it becomes impractical, and that bugs affecting only those versions may not be treated as release blockers. In practice that means a failure you hit on Node 20 or Safari 26 may be acknowledged and left open rather than fixed on your schedule. The README also says that other browsers, and older and newer versions of some supported browsers, are likely to work but are not tested and are not actively supported. If your product ships to a browser outside that table, you are the one testing it.

There is a second constraint in the same section: for evergreen browsers, each release is tested against whatever version was available at release time. Support is therefore a snapshot, not a rolling guarantee. The README tells you to consult the release notes to find out which environments work with a particular release, which is the only reliable way to answer the question for a version you have already pinned.

## Where jasmine/jasmine is the wrong tool

The framework's independence from other libraries is a trade-off, not a free win. Because it does not depend on a DOM, it also does not provide one. Anything that needs a rendered document, layout, or real browser APIs has to be supplied by the surrounding setup, and the README does not describe that setup. Projects whose tests are mostly component rendering will spend their time wiring an environment rather than writing expectations.

The published package boundary is the second limit. jasmine-core's files field ships lib, images, the licence, the readme and package.json. There is no test runner binary in that list, so installing jasmine-core alone does not give you a command to execute. You either add the separate jasmine package, which the repository itself uses as a devDependency, or drive the core from your own harness. Teams that expect a single dependency to both define expectations and discover and run files will find the split surprising.

Finally, the README is thin on operational detail. It documents installation only by reference to the Getting Started page, and it does not document configuration keys, reporters, or how to run a subset of specs. Those answers exist on the documentation site, but a reader who only opens the repository will not find them there.

## How it compares with a framework that bundles a DOM and a runner

The clearest contrast is with frameworks that treat the browser environment as part of the product. Those projects ship a virtual DOM, a component renderer, and a watch-mode runner in one install, so a component test works immediately. Jasmine makes the opposite choice: the core is environment-agnostic, and everything specific to an environment is left to the caller. That is why the same spec file can run under Node and under a served browser page, and it is why the repository carries a script that starts a local browser page for its own suite.

The practical difference shows up in setup and in failure modes. With a bundled environment you get a working default and inherit its opinions about module resolution and rendering. With Jasmine you get a small core and a configuration file you write yourself, and you own the environment. Neither is better in the abstract; they fail in different places. If your tests are mostly logic and you want them to run in more than one host, the split design pays off. If your tests are mostly rendering, you are paying for flexibility you will not use. Note also that the README does not position the project against any named alternative, so any comparison has to be drawn from the two projects' own documentation.

## Licence, maintenance and the cost of upgrading

The repository is licensed under the MIT License, and the README carries the copyright line through 2026 with The Jasmine developers after the earlier Pivotal Labs years. The package.json license field is MIT as well. For most consumers that means permissive reuse with the licence text retained; this is a description of the published terms, not legal advice, and the LICENSE file in the repository is the authoritative text.

Maintenance signals are concrete. The repository is not archived, and the last push was on 2026-08-20. The most recent releases are v7.0.0 and v7.0.1, both on 2026-08-15, after two pre-releases in June. The package.json version reads 7.0.2, which is ahead of the newest published release in the list, so the repository is carrying unreleased work on main.

Upgrade cost is dominated by the environment table, not by the API. A major version bump can drop a Node or browser version from the tested set, and the README's own wording says best-effort versions may be dropped when it becomes impractical. There is a release_notes directory in the repository, and the README directs readers to it to find out which environments a given release supports. That directory is the thing to read before pinning a new major, because the README will not tell you.

## Conclusion

Adopt jasmine/jasmine if you want a BDD-style JavaScript test framework whose specs run unchanged in Node and in a browser and whose only runtime dependency is its own core package. Do not adopt it if you need a built-in watch mode, a snapshot format, or a runner that discovers files without configuration; the README does not describe any of those. Before committing, check the supported environment table against your Node and browser versions, and read the release notes for the version you plan to pin, because the README states that support for best-effort versions may be dropped without being treated as a release blocker.

## FAQ

### How do I install jasmine for a Node.js project?

The README does not list install commands and instead links to the Getting Started page, which covers the options per environment. The repository's own package.json uses the jasmine package as a devDependency, while the published core package is named jasmine-core.

### How do I install jasmine and Karma together in Angular?

The README, the repository file list and the package metadata do not mention Karma or Angular, so there is nothing in this material to base that setup on. The supported environments table lists Node and the browsers Safari, Chrome, Firefox and Edge.

### Does jasmine require a browser or a DOM to run tests?

No. The README states that Jasmine does not rely on browsers, DOM, or any JavaScript framework, and that it is suited for websites, Node.js projects, or anywhere JavaScript can run. The repository's own test script runs the specs in Node.

### Which Node and browser versions does jasmine support?

The README's table lists Node 20, 22, 24 and 26, Safari 26, evergreen Chrome and Edge, and Firefox evergreen plus 140. Node 20 and Safari 26 are marked as supported on a best-effort basis, and the README says bugs affecting only those versions may not be treated as release blockers.

### What is the difference between jasmine and jasmine-core?

The repository's package.json sets the name to jasmine-core and points main at ./lib/jasmine-core.js, and its files field ships only the licence, readme, images, lib and package.json. The jasmine package appears separately in the repository's devDependencies as the runner.

### What licence does jasmine use?

The repository is licensed under the MIT License, and the package.json license field is MIT. The README carries a copyright line through 2026 attributed to The Jasmine developers, following the earlier Pivotal Labs years.

## Sources

- [jasmine/jasmine on GitHub](https://github.com/jasmine/jasmine)
- [License: MIT](https://github.com/jasmine/jasmine/blob/main/LICENSE)
- [Project website](http://jasmine.github.io/)
- [README](https://github.com/jasmine/jasmine/blob/main/README.md)
- [Releases](https://github.com/jasmine/jasmine/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/jasmine-jasmine