Jasmine

This guide covers Jasmine 4.0 or newer. You need Node.js 22.12 or newer to run test-inventory and an existing JavaScript or TypeScript test suite. The scanner reads your source without executing your tests or starting a browser. These are minimum supported versions; CI comparisons list tested versions.

Choose another framework · Use an AI client

Install

npm install --save-dev test-inventory

Scan your suite

Run from the folder containing your project's package.json:

npx test-inventory --framework jasmine --pretty --output inventory.json

To select files explicitly, use quoted globs. This example matches the risk-service fixture used below; adjust the globs to your suite's layout:

npx test-inventory "spec/*.spec.js" "spec/limits/**/*.spec.js" --framework jasmine --output inventory.json

The command replaces inventory.json once the new output is complete. It does not change your test files.

Check the result

Print the counts and diagnostics from the saved file:

node -e "const i = require('./inventory.json'); console.log(i.summary); console.log(i.diagnostics)"

For matching tests, summary.fileCount and summary.testCount should be greater than zero. Review diagnostics even when the command exits with 0: errors can mean tests are missing. If the result is empty or unexpected, use troubleshooting.

The inventory describes source declarations, not execution results. Conditional skips are not proof that a run skipped the test. Loops and tables are one record by default; supported cases can be expanded with --expand-cases. Expected-to-fail tests execute and check for failure; they are not disabled tests.

Tests created by unreadable helpers can be missing without a diagnostic. A dependency hash does not prove complete coverage of runtime dependencies. Read the shared limits before using scans to make CI decisions.

Find skipped tests

npx test-inventory --framework jasmine --state skip --fields fullName,state,condition,reason --pretty

This uses the same file selection as the first scan. If you supplied globs, --root or --framework-version, repeat those options here.

This selects source declarations marked skip; it is not a report of a test run. See query recipes for other inventory queries.

Example

risk-service measures exposure and value at risk, and is tested with the jasmine command, in plain CommonJS. Its config, spec/support/jasmine.json, runs **/*.spec.js under spec, and its !fixtures/** leaves the sample positions out.

Specs mark themselves pending at run time, with a reason, and take a timeout as their third argument:

// spec/exposure.spec.js
  it('reads positions from the prime broker', async () => {
    expect(positions.length).toBe(2);
  }, 15_000);
  // ...
  it('includes futures at their notional', () => {
    pending('RISK-81: futures need the contract multiplier');
  });

  it('includes positions in the overnight session', () => {
    if (!process.env.EXTENDED_HOURS) pending('Only with extended hours');

npx test-inventory "spec/*.spec.js" "spec/limits/**/*.spec.js" --framework jasmine --output inventory.json

Without the globs and --framework, the scan finds the same files from jasmine.json, and Jasmine from package.json. pending() keeps its reason, and under a condition the test is conditional:

{
  "fullName": "exposure > includes positions in the overnight session",
  "state": "skip",
  "isConditional": true,
  "condition": "!process.env.EXTENDED_HOURS",
  "reason": "Only with extended hours"
}

Configuration and limits

The scan reads spec/support/jasmine.mjs from Jasmine 5, then .json or .js, in the root. Without a config it selects no files unless files are explicitly supplied, as Karma and Angular supply them. Scan globs replace spec_files; JASMINE_CONFIG_PATH and the runner's --config are not read.

Helper globs are included in dependency hashes. Setup and helper code is not executed to discover arbitrary runtime effects. The record describes pending() and disabled declarations from source, not a result from a run.

Exact file selection

For Jasmine: the files under spec_dir that a spec_files glob matches, without those a glob starting with ! matches. Without a config it runs no file; scanned with globs, every file they match counts as run, as files given to Jasmine replace spec_files. JASMINE_CONFIG_PATH and --config are not read.

Supported syntax

Jasmine 4.0 and newer.

Where test comes from

Form	Example
Globals	describe, xdescribe, fdescribe, it, xit and fit, which the jasmine command, Karma or a browser page set; Jasmine has no module to import them from
Kept in a variable	const later = xit: the variable keeps the x or f; of a choice, also one written in place, as (process.env.CI ? xit : it)(...), only what both branches share applies
Local helpers file	import { spec } from './helpers' or require('./helpers'), followed through local imports, and helper functions that declare specs, read at each call

xit and xdescribe are .skip, and fit and fdescribe .only. Jasmine's functions have no members, so a call such as it.only() is an invalid-chain error. Jasmine runs the innermost focus: a fit or fdescribe runs also inside an xdescribe, while an xdescribe inside an fdescribe stays skipped, and in an fdescribe with a fit or fdescribe below it, only those run, so its other specs have isOnly: false. WebdriverIO on Jasmine follows the same rules.

Calls

Call	Read as
it(title, fn), it(title, fn, timeout)	A spec, with timeout when the third argument is a number the scan can work out.
it(title), xit(title) without a function, or with undefined	A skipped spec: Jasmine reports it as pending; it() is one titled ''. fit(title) without one is a test-without-body error.
it(title, 42)	A test-without-body error: Jasmine takes the function second.
describe(title, fn)	A describe. Without a function, a test-without-body error, also for xdescribe; with an async callback, an async-describe error; with a callback whose length is above 0, as (fills) => {}, or that declares no spec or describe, as one with only hooks, a describe-throws error.
beforeAll, beforeEach, afterEach, afterAll	Hooks, also with a timeout as their second argument.
pending(reason) in a spec, beforeEach or afterEach	The spec skipped with the reason; under a condition, isConditional. In beforeAll or afterAll, Jasmine reports it as an error of the describe, and the specs keep their state.
notApplicable(reason) in a spec	From Jasmine 7, the spec skipped with the reason. Before, the call fails the spec.

Where an error is written decides what Jasmine does. At the top level of a file, it stops Jasmine before it runs any spec, in this file or any other, and every test in the file is notLoaded. Inside a describe, Jasmine catches it: it reports the describe as failed and registers none of the specs written after the call in it; the scan reports the error, keeps the file's tests as they are, and still lists those later specs. jasmine.DEFAULT_TIMEOUT_INTERVAL set in a helper or spec file is not read. A beforeEach in a helper file runs around every spec, but is not counted in hooks.

The shared syntax rules also apply.

Next

• Shared limits: imports, generated tests, conditions and dependency coverage.
• Key concepts: counts, states, IDs and hashes.
• Output reference and diagnostics: interpret every field and warning.
• CLI, library and MCP: use the same inventory through each interface.
• Compare with Jasmine: differences from runner collection and execution reports.