# karma-jasmine: the adapter that plugs Jasmine into Karma

> karma-jasmine is the adapter that lets Karma run Jasmine in a real browser, and its features go well beyond loading the framework. It can filter specs by name, print a debug URL that opens a single failing test, pass Jasmine its own configuration, and partition specs across shards.

**karma-runner/karma-jasmine** — A Karma plugin - adapter for Jasmine testing framework.

- Repository: https://github.com/karma-runner/karma-jasmine
- Stars: 535 · Forks: 163
- Language: JavaScript
- License: MIT
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/karma-runner-karma-jasmine

## An adapter whose whole job is wiring Jasmine into Karma

karma-jasmine is a Karma plugin, described as an adapter for the Jasmine testing framework, and it is published on npm as karma-jasmine.

The installation is one dev dependency:

```bash
npm install karma-jasmine --save-dev
```

And the configuration is the standard Karma shape with the frameworks key set to jasmine:

```js
// karma.conf.js
module.exports = function(config) {
  config.set({
    frameworks: ['jasmine'],
    files: [
      '*.js'
    ]
  })
}
```

That is the whole surface area of the plugin, and it is worth being clear about what that means. Karma is a test runner that launches a browser, serves your files into it and reports the results back. Jasmine is a test framework that runs inside the browser. The adapter is the piece that tells Karma how to load Jasmine, how to report its results, and how to hand it configuration.

The plugin manifest makes the shape explicit. The main entry is lib/index.js, the published files array contains only lib/*.js, and the single runtime dependency is jasmine-core at version 4.1.0 or newer. Karma itself is a peer dependency at version 6.0.0 or newer rather than a direct dependency, which is the correct arrangement for a Karma plugin: the plugin and the runner have to agree on the version, and the runner is the thing the user installs.

The declared engines field requires Node 12 or newer.

The project is MIT licensed, the primary language is JavaScript, and the recent releases are v5.0.0, v5.0.1 and v5.1.0, all in the first half of 2022, with the last push on 2026-06-20. The version field in the package manifest reads 4.0.1, which is behind the newest tag, so the manifest shown here is not the one behind the current release.

The author recorded in the manifest is Vojta Jina, with Maksim Ryzhikov listed as a contributor, and the project sits in the karma-runner organisation alongside the other Karma plugins.

## Grep filtering, and the two ways to pass the pattern in

The first feature beyond basic wiring is running only the tests whose names match a pattern, and the plugin supports two ways of doing it.

The first is through the command line, starting the runner in the background and then running a filtered subset:

```bash
$ karma start &
$ karma run -- --grep=<pattern>
```

The pattern is either a string or a regular expression. A string such as a hash-prefixed tag runs the tests containing that string, and a regular expression such as a negative lookahead runs the tests that do not contain it. The negative lookahead form is the interesting one, because it is the only way to express a set difference in a single pattern, and a tagged-test convention is exactly the case where you want it.

The second way is through the configuration file, which the documentation describes as passing it to karma.config.js:

```js
module.exports = function(config) {
  config.set({
    client: {
      jasmine: {
        random: true,
        seed: '4321',
        oneFailurePerSpec: true,
        failFast: true,
        timeoutInterval: 1000
      }
    }
  })
```

The client args array is passed to the browser side, and the pattern is given as two entries so that the value with its leading dashes is not mistaken for a Karma option. Putting it in the config means the filtered subset is recorded in the file, so everyone running the suite runs the same subset, rather than depending on what somebody typed on the command line.

The third feature is passing Jasmine's own configuration directly. The client.jasmine object accepts random, seed, oneFailurePerSpec, failFast and timeoutInterval.

The seed is the one worth knowing about. Setting a fixed seed makes the order of the randomised specs reproducible, which is how you debug a test that only fails in some orders. random true is Jasmine's own default behaviour of shuffling specs, and oneFailurePerSpec, failFast and timeoutInterval are the knobs for how much the suite tells you when something breaks.

Putting the two together is the point. The grep filter narrows the suite to what you care about, and the fixed seed makes that subset deterministic, so a failing test fails the same way every time you run it.

## A debug URL per failure, and the single spec mode that uses it

There is a debugging feature that is small in description and unusually useful in practice.

Failing tests print a debug URL with a spec query parameter. The instruction is to use it with the no_single_run flag and paste it into your browser to focus on a single failing test.

The mechanism is worth understanding. When a spec fails, Karma reports the failure and the adapter constructs a URL that points back at the runner with a query parameter identifying that one spec. Opening that URL in a browser puts the browser into a mode where the runner serves only that spec.

The no_single_run flag is what makes it work, and it is the part that is easy to miss. By default Karma runs once and exits, which is what you want in continuous integration. With single run disabled the server stays up, so a URL can be opened against a live runner. The two are different modes for different purposes, and the debug URL belongs to the second.

The alternative workflow is the familiar one, where you set a breakpoint in the browser's developer tools and re-run the suite until it fails again. The debug URL replaces that with a single navigation, and it works even when the failure is order dependent, because the spec is isolated from the rest.

For a plugin whose job is otherwise to launch a browser and collect results, this is a real quality of life feature. It is the kind of thing that a test runner team adds after spending years watching people re-run suites by hand.

The repository carries a wallaby.js file at the top level, which is the configuration for Wallaby.js, the editor-integrated test runner that keeps a watcher running. That is consistent with the no_single_run mode existing at all, since a continuous runner and a per-failure debug URL belong to the same way of working.

## Sharding is declared but the integration is not finished

The sharding feature is the one place in the documentation where the project says plainly that something is not finished, and it is worth quoting the limitation rather than paraphrasing it.

By setting config.client.shardIndex and config.client.totalShards, you can run a subset of the full set of specs. Complete sharding support needs to be done in the process that calls Karma, and would need to support test result integration across shards.

So the adapter can partition the specs, and the gap is in what happens afterwards. The client side knows which shard it is, but the process that invoked Karma is the one that would have to launch several shards and merge what they report, and merging results from multiple browsers back into a single pass or fail verdict is not something the adapter can do on its own.

That is an honest boundary. Sharding is easy to fake badly, because a runner that runs shard one of four and reports success is worse than a runner that does not shard at all. Leaving the orchestration to the calling process is the right call, and saying so is what lets somebody build it.

For a team running a large browser suite in continuous integration, this is the feature to watch. The partition half exists today, so the work needed is on the caller side, and the documentation points at exactly what that work involves.

It also sits naturally beside the grep filter described earlier, since both are about reducing the set of specs a run has to execute. Grep narrows by name within a run, sharding narrows by index across runs, and the two compose if the caller does the merging.

## A custom spec filter, and the example that proves it works

The last feature is support for a custom spec filter, and it is documented with an example rather than just a link to the Jasmine API.

Providing a custom spec filter is also supported, and the example shows users able to set a custom specFilter themselves:

```js
// Users are able to set a custom specFilter themselves

jasmine.getEnv().configure({
  specFilter: function (spec) {
    return spec.getFullName() === 'spec that succeeds'
  }
})

describe('spec', () => {
  it('that fails', () => {
    fail('This spec should not run!')
  })

  it('that succeeds', () => {
    expect(1).toBe(1)
  })
```

The mechanism is Jasmine's own. Calling getEnv on the Jasmine object and then configure with a specFilter replaces the filter Jasmine uses to decide which specs to run. The filter receives the spec and returns whether to include it.

The example is deliberately a trap for the reader. There are two specs, one that fails and one that succeeds. The filter compares the full name of the spec against a single string, the name of the one that succeeds, so the failing spec is excluded and the suite passes. The failing spec calls a fail function with a message saying it should not run, and the assertion that it would fail is the point of the demonstration.

The comparison uses getFullName rather than the spec's own name, and that is the detail to get right. getFullName returns the concatenated description path, so in a nested describe and it structure it is the whole path rather than the it string alone. A filter that compares against the short name would silently exclude nothing, since short names are rarely unique.

This is the most powerful of the features, and it is also the most dangerous, because a filter that excludes the wrong spec produces a green suite. The example handles that risk by including a spec designed to fail and asserting it does not run.

The practical value is real though. A filter that depends on an environment variable, so that a developer can run only the specs touching the area they are working on, or that excludes specs known to be flaky in a particular browser, is the kind of thing the Jasmine configuration API allows and that this adapter exposes without further work.

## The build is Grunt, the release is semantic-release, and the tests are three kinds

The package manifest describes a project with an older but perfectly coherent toolchain, and reading the scripts tells you how it works.

The build is grunt build, and the lint is eslint with a fix variant. The style is js-standard-style, with the standard eslint config and its plugin set, and the eslintignore and editorconfig files are both at the top level. The commit messages are checked by commitlint with the angular config, wired through husky with a commit-msg hook that passes the commit parameters to it.

The test script chains three kinds of test, and each maps to a different thing being verified.

The unit test is plain jasmine, which is the framework's own runner with no Karma involved. The end-to-end test is karma start karma.conf.js, which is the plugin running its own runner on its own configuration, which is the closest thing to a self-test a plugin like this can have. The integration test is a shell script, bash tools/integration-tests.sh.

That three-way split is the part worth noting. The unit tests check the adapter's own logic without a browser. The end-to-end test exercises the plugin inside Karma, which is the arrangement where a broken interface between the two would show up. And the integration script is presumably where the plugin is installed into a scratch project and run against a real Karma setup, which is the only way to catch a packaging mistake where the published files array does not include something the plugin needs at runtime.

The releases are handled by semantic-release, with the changelog, git, github and npm plugins configured, and a release.config.js at the top level alongside a release workflow badge. The CHANGELOG.md in the repository is generated by that tooling, which is why the version tags are conventional.

The remaining top level entries explain themselves. There is a gruntfile.js for the build tasks, a tasks/ directory for the grunt task definitions, a lib/ directory for the published output, a src/ directory for the source, a spec/ directory, a test/ directory, a tools/ directory for the integration script, and a karma.conf.js for the end-to-end run.

The project is MIT licensed, with a LICENSE file and a CONTRIBUTING.md at the root.

## Conclusion

karma-jasmine suits a browser project that runs its tests in Karma and wants Jasmine's ergonomics without giving up the features Karma already has, and the debug URL and the grep filter together remove most of the friction of debugging an order dependent failure. It does not suit you if you need sharding to work end to end today, because the adapter can partition the specs but the merging of results across shards has to be built in the process that calls Karma. Before you upgrade to a newer major version, note that the manifest shown here reads 4.0.1 while the newest tag is 5.1.0, and check the peer dependency on Karma, since version 6 or newer is required.

## FAQ

### How do I install karma-jasmine and configure it?

Run npm install karma-jasmine --save-dev, then set frameworks to jasmine in your karma.conf.js. The plugin is published on npm as karma-jasmine and declares karma as a peer dependency at version 6.0.0 or newer.

### How do I run only the Karma Jasmine tests matching a pattern?

Start the runner with karma start in the background and run karma run with a grep argument, for example karma run -- --grep=<pattern>. The pattern is either a string, so a hash-prefixed tag runs the tests containing it, or a regular expression, so a negative lookahead runs the tests that do not contain it. You can also set client.args with the grep and pattern entries in the config file.

### What is the debug URL that a failing Karma Jasmine test prints?

It is a URL with a spec query parameter pointing at the runner for that one failing test. Use it with the no_single_run flag and paste it into your browser to focus on a single failing spec, which works because the runner stays up in that mode.

### Does karma-jasmine support sharding?

Partly. Setting config.client.shardIndex and config.client.totalShards runs a subset of the specs, but the documentation is explicit that complete sharding support needs to be done in the process that calls Karma and would need to support test result integration across shards.

### How do I pass configuration options straight to Jasmine?

Through the client.jasmine object in the Karma config, which accepts random, seed, oneFailurePerSpec, failFast and timeoutInterval. A fixed seed makes the randomised spec order reproducible, which is what you want when a failure depends on ordering.

## Sources

- [Issues](https://github.com/karma-runner/karma-jasmine/issues)
- [karma-runner/karma-jasmine on GitHub](https://github.com/karma-runner/karma-jasmine)
- [License: MIT](https://github.com/karma-runner/karma-jasmine/blob/master/LICENSE)
- [README](https://github.com/karma-runner/karma-jasmine/blob/master/README.md)
- [Releases](https://github.com/karma-runner/karma-jasmine/releases)

---

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