jest Documentation

Delightful JavaScript Testing.

45,467 stars TypeScript TypeScript 1 file · ~13,834 tokens #easy#expectation#facebook#immersive#javascript#painless#painless-javascript-testing#snapshot
RAW Doc

File: README.md

 

🃏 Delightful JavaScript Testing

👩🏻‍💻 Developer Ready: A comprehensive JavaScript testing solution. Works out of the box for most JavaScript projects.

🏃🏽 Instant Feedback: Fast, interactive watch mode only runs test files related to changed files.

📸 Snapshot Testing: Capture snapshots of large objects to simplify testing and to analyze how they change over time.

See more on jestjs.io

Table of Contents

Getting Started

Install Jest using yarn:

bash
yarn add --dev jest

Or npm:

bash
npm install --save-dev jest

Note: Jest documentation uses yarn commands, but npm will also work. You can compare yarn and npm commands in the yarn docs, here.

Let's get started by writing a test for a hypothetical function that adds two numbers. First, create a sum.js file:

javascript
function sum(a, b) {
  return a + b;
}
module.exports = sum;

Then, create a file named sum.test.js. This will contain our actual test:

javascript
const sum = require('./sum');

test('adds 1 + 2 to equal 3', () => {
  expect(sum(1, 2)).toBe(3);
});

Add the following section to your package.json:

json
{
  "scripts": {
    "test": "jest"
  }
}

Finally, run yarn test or npm test and Jest will print this message:

bash
PASS  ./sum.test.js
✓ adds 1 + 2 to equal 3 (5ms)

You just successfully wrote your first test using Jest!

This test used expect and toBe to test that two values were exactly identical. To learn about the other things that Jest can test, see Using Matchers.

Running from command line

You can run Jest directly from the CLI (if it's globally available in your PATH, e.g. by yarn global add jest or npm install jest --global) with a variety of useful options.

Here's how to run Jest on files matching my-test, using config.json as a configuration file and display a native OS notification after the run:

bash
jest my-test --notify --config=config.json

If you'd like to learn more about running jest through the command line, take a look at the Jest CLI Options page.

Additional Configuration

Generate a basic configuration file

Based on your project, Jest will ask you a few questions and will create a basic configuration file with a short description for each option:

bash
yarn create jest

Using Babel

To use Babel, install required dependencies via yarn:

bash
yarn add --dev babel-jest @babel/core @babel/preset-env

Configure Babel to target your current version of Node by creating a babel.config.js file in the root of your project:

javascript
// babel.config.js
module.exports = {
  presets: [['@babel/preset-env', {targets: {node: 'current'}}]],
};

The ideal configuration for Babel will depend on your project. See Babel's docs for more details.

Making your Babel config jest-aware

Jest will set process.env.NODE_ENV to 'test' if it's not set to something else. You can use that in your configuration to conditionally setup only the compilation needed for Jest, e.g.

javascript
// babel.config.js
module.exports = api => {
  const isTest = api.env('test');
  // You can use isTest to determine what presets and plugins to use.

  return {
    // ...
  };
};

Note: babel-jest is automatically installed when installing Jest and will automatically transform files if a babel configuration exists in your project. To avoid this behavior, you can explicitly reset the transform configuration option:

javascript
// jest.config.js
module.exports = {
  transform: {},
};

Using webpack

Jest can be used in projects that use webpack to manage assets, styles, and compilation. webpack does offer some unique challenges over other tools. Refer to the webpack guide to get started.

Using Vite

Jest can be used in projects that use vite to serves source code over native ESM to provide some frontend tooling, vite is an opinionated tool and does offer some out-of-the box workflows. Jest is not fully supported by vite due to how the plugin system from vite works, but there is some working examples for first-class jest integration using the vite-jest, since this is not fully supported, you might as well read the limitation of the vite-jest. Refer to the vite guide to get started.

Using Parcel

Jest can be used in projects that use parcel-bundler to manage assets, styles, and compilation similar to webpack. Parcel requires zero configuration. Refer to the official docs to get started.

Using TypeScript

Jest supports TypeScript, via Babel. First, make sure you followed the instructions on using Babel above. Next, install the @babel/preset-typescript via yarn:

bash
yarn add --dev @babel/preset-typescript

Then add @babel/preset-typescript to the list of presets in your babel.config.js.

diff
// babel.config.js
module.exports = {
  presets: [
    ['@babel/preset-env', {targets: {node: 'current'}}],
+    '@babel/preset-typescript',
  ],
};

However, there are some caveats to using TypeScript with Babel. Because TypeScript support in Babel is purely transpilation, Jest will not type-check your tests as they are run. If you want that, you can use ts-jest instead, or just run the TypeScript compiler tsc separately (or as part of your build process).

Documentation

Learn more about using Jest on the official site!

Badge

Show the world you're using Jest →

md
[](https://github.com/jestjs/jest)
[](https://github.com/jestjs/jest)
[](https://github.com/jestjs/jest)

Contributing

Development of Jest happens in the open on GitHub, and we are grateful to the community for contributing bugfixes and improvements. Read below to learn how you can take part in improving Jest.

[Code of Conduct](https://code.facebook.com/codeofconduct)

Facebook has adopted a Code of Conduct that we expect project participants to adhere to. Please read the full text so that you can understand what actions will and will not be tolerated.

[Contributing Guide](CONTRIBUTING.md)

Read our contributing guide to learn about our development process, how to propose bugfixes and improvements, and how to build and test your changes to Jest.

[Good First Issues](https://github.com/jestjs/jest/labels/good%20first%20issue)

To help you get your feet wet and get you familiar with our contribution process, we have a list of good first issues that contain bugs which have a relatively limited scope. This is a great place to get started.

Credits

This project exists thanks to all the people who contribute.

[Backers](https://opencollective.com/jest#backer)

Thank you to all our backers! 🙏

[Sponsors](https://opencollective.com/jest#sponsor)

Support this project by becoming a sponsor. Your logo will show up here with a link to your website.

License

Jest is MIT licensed.

Copyright Contributors to the Jest project.

File: benchmarks/test-file-overhead/README.md

First, run ./prepare.sh to generate the benchmark files. On Windows, use a Bash (WSL, Git, Cygwin …) to do this, but you can use CMD for the actual benchmark run if the CMD environment is what you want to benchmark for.

To run the benchmark, use a benchmarking tool such as hyperfine:

sh
hyperfine -w 3 -m 10 ../../jest /tmp/other-jest-clone-to-compare-against/jest

File: docs/_TypeScriptExamplesNote.md

:::info

The TypeScript examples from this page will only work as documented if you explicitly import Jest APIs:

ts
import {expect, jest, test} from '@jest/globals';

Consult the Getting Started guide for details on how to setup Jest with TypeScript.

:::

File: docs/Architecture.md

id: architecture title: Architecture

import LiteYouTubeEmbed from 'react-lite-youtube-embed';

If you are interested in learning more about how Jest works, understand its architecture, and how Jest is split up into individual reusable packages, check out this video:

If you'd like to learn how to build a testing framework like Jest from scratch, check out this video:

There is also a written guide you can follow. It teaches the fundamental concepts of Jest and explains how various parts of Jest can be used to compose a custom testing framework.

File: docs/BypassingModuleMocks.md

id: bypassing-module-mocks title: Bypassing module mocks

Jest allows you to mock out whole modules in your tests, which can be useful for testing if your code is calling functions from that module correctly. However, sometimes you may want to use parts of a mocked module in your test file, in which case you want to access the original implementation, rather than a mocked version.

Consider writing a test case for this createUser function:

javascript title="createuser.js"
import fetch from 'node-fetch';

export const createUser = async () => {
  const response = await fetch('https://website.com/users', {method: 'POST'});
  const userId = await response.text();
  return userId;
};

Your test will want to mock the fetch function so that we can be sure that it gets called without actually making the network request. However, you'll also need to mock the return value of fetch with a Response (wrapped in a Promise), as our function uses it to grab the created user's ID. So you might initially try writing a test like this:

javascript
jest.mock('node-fetch');

import fetch, {Response} from 'node-fetch';
import {createUser} from './createUser';

test('createUser calls fetch with the right args and returns the user id', async () => {
  fetch.mockReturnValue(Promise.resolve(new Response('4')));

  const userId = await createUser();

  expect(fetch).toHaveBeenCalledTimes(1);
  expect(fetch).toHaveBeenCalledWith('https://website.com/users', {
    method: 'POST',
  });
  expect(userId).toBe('4');
});

However, if you ran that test you would find that the createUser function would fail, throwing the error: TypeError: response.text is not a function. This is because the Response class you've imported from node-fetch has been mocked (due to the jest.mock call at the top of the test file) so it no longer behaves the way it should.

To get around problems like this, Jest provides the jest.requireActual helper. To make the above test work, make the following change to the imports in the test file:

javascript
// BEFORE
jest.mock('node-fetch');
import fetch, {Response} from 'node-fetch';
javascript
// AFTER
jest.mock('node-fetch');
import fetch from 'node-fetch';
const {Response} = jest.requireActual('node-fetch');

This allows your test file to import the actual Response object from node-fetch, rather than a mocked version. This means the test will now pass correctly.

File: docs/CLI.md

id: cli title: Jest CLI Options

The jest command line runner has a number of useful options. You can run jest --help to view all available options. Many of the options shown below can also be used together to run tests exactly the way you want. Every one of Jest's Configuration options can also be specified through the CLI.

Here is a brief overview:

Running from the command line

Run all tests (default):

bash
jest

Run only the tests that were specified with a pattern or filename:

bash
jest my-test #or
jest path/to/my-test.js

Run tests related to changed files based on hg/git (uncommitted files):

bash
jest -o

Run tests related to path/to/fileA.js and path/to/fileB.js:

bash
jest --findRelatedTests path/to/fileA.js path/to/fileB.js

Run tests that match this spec name (match against the name in describe or test, basically).

bash
jest -t name-of-spec

Run watch mode:

bash
jest --watch #runs jest -o by default
jest --watchAll #runs all tests

Watch mode also enables to specify the name or path to a file to focus on a specific set of tests.

Using with package manager

If you run Jest via your package manager, you can still pass the command line arguments directly as Jest arguments.

Instead of:

bash
jest -u -t="ColorPicker"

you can use:

bash npm2yarn
npm test -- -u -t="ColorPicker"

Camelcase & dashed args support

Jest supports both camelcase and dashed arg formats. The following examples will have an equal result:

bash
jest --collect-coverage
jest --collectCoverage

Arguments can also be mixed:

bash
jest --update-snapshot --detectOpenHandles

Options

:::note

CLI options take precedence over values from the Configuration.

:::

import TOCInline from '@theme/TOCInline';

Reference

`jest `

When you run jest with an argument, that argument is treated as a regular expression to match against files in your project. It is possible to run test suites by providing a pattern. Only the files that the pattern matches will be picked up and executed. Depending on your terminal, you may need to quote this argument: jest "my.*(complex)?pattern". On Windows, you will need to use / as a path separator or escape \ as \\.

`--bail[=]`

Alias: -b. Exit the test suite immediately upon n number of failing test suite. Defaults to 1.

`--cache`

Whether to use the cache. Defaults to true. Disable the cache using --no-cache.

:::caution

The cache should only be disabled if you are experiencing caching related problems. On average, disabling the cache makes Jest at least two times slower.

:::

If you want to inspect the cache, use --showConfig and look at the cacheDirectory value. If you need to clear the cache, use --clearCache.

`--changedFilesWithAncestor`

Runs tests related to the current changes and the changes made in the last commit. Behaves similarly to --onlyChanged.

`--changedSince`

Runs tests related to the changes since the provided branch or commit hash. If the current branch has diverged from the given branch, then only changes made locally will be tested. Behaves similarly to --onlyChanged.

`--ci`

When this option is provided, Jest will assume it is running in a CI environment. This changes the behavior when a new snapshot is encountered. Instead of the regular behavior of storing a new snapshot automatically, it will fail the test and require Jest to be run with --updateSnapshot.

`--clearCache`

Deletes the Jest cache directory and then exits without running tests. Will delete cacheDirectory if the option is passed, or Jest's default cache directory. The default cache directory can be found by calling jest --showConfig.

:::caution

Clearing the cache will reduce performance.

:::

`--clearMocks`

Automatically clear mock calls, instances, contexts and results before every test. Equivalent to calling jest.clearAllMocks() before each test. This does not remove any mock implementation that may have been provided.

`--collectCoverageFrom=`

A glob pattern relative to rootDir matching the files that coverage info needs to be collected from.

`--collectTests`

Discover and print all test suites and test names without executing them. Jest loads each test file, evaluates the top-level describe blocks to register tests, then exits before running any test code or lifecycle hooks.

Output is a tree of file paths with their nested describe and test names, followed by a summary of the total counts. Skipped and todo tests are annotated, and any file that throws while loading is reported with its error (and the exit code is non-zero):

text
path/to/my.test.ts
  My suite
    passes
    skips [skipped]
    write later [todo]

Test suites: 1
Tests:       3 total, 1 runnable, 1 skipped, 1 todo

Parametrized tests declared with test.each / describe.each are expanded to one entry per case, and each collected test is categorized exactly as a real run would categorize it:

  • a test that would run is reported in the passed bucket and flagged wouldRun: true (it was selected but never executed);
  • test.skip, tests inside a skipped describe, tests deselected by test.only, and tests excluded by --testNamePattern are reported as pending;
  • test.todo is reported as todo.

Because every test is accounted for in the same bucket an actual run would use, the counts reported by --collectTests match those of a run in which every selected test passes — so it can be used to count tests without executing them, including under --testNamePattern.

Use --json to get machine-readable output instead. The JSON uses the same shape as a normal run, including numTotalTests, numPassedTests, numPendingTests and numTodoTests, and each assertion carries the wouldRun flag described above.

`--colors`

Forces test results output highlighting even if stdout is not a TTY.

:::note

Alternatively you can set the environment variable FORCE_COLOR=true to forcefully enable or FORCE_COLOR=false to disable colorized output. The use of FORCE_COLOR overrides all other color support checks.

:::

`--config=`

Alias: -c. The path to a Jest config file specifying how to find and execute tests. If no rootDir is set in the config, the directory containing the config file is assumed to be the rootDir for the project. This can also be a JSON-encoded value which Jest will use as configuration.

`--coverage[=]`

Alias: --collectCoverage. Indicates that test coverage information should be collected and reported in the output. Optionally pass `` to override option set in configuration.

`--coverageDirectory=`

The directory where Jest should output its coverage files.

`--coverageProvider=`

Indicates which provider should be used to instrument code for coverage. Allowed values are babel (default) or v8.

`--debug`

Print debugging info about your Jest config.

`--detectOpenHandles`

Attempt to collect and print open handles preventing Jest from exiting cleanly. Use this in cases where you need to use --forceExit in order for Jest to exit to potentially track down the reason. This implies --runInBand, making tests run serially. Implemented using async_hooks. This option has a significant performance penalty and should only be used for debugging.

`--env=`

The test environment used for all tests. This can point to any file or node module. Examples: jsdom, node or path/to/my-environment.js.

`--errorOnDeprecated`

Make calling deprecated APIs throw helpful error messages. Useful for easing the upgrade process.

`--expand`

Alias: -e. Use this flag to show full diffs and errors instead of a patch.

`--filter=`

Path to a module exporting a filtering function. This asynchronous function receives a list of test paths which can be manipulated to exclude tests from running and must return an object with shape { filtered: Array<string> } containing the tests that should be run by Jest. Especially useful when used in conjunction with a testing infrastructure to filter known broken tests.

js title="my-filter.js"
// This filter when applied will only run tests ending in .spec.js (not the best way to do it, but it's just an example):
const filteringFunction = testPath => testPath.endsWith('.spec.js');

module.exports = testPaths => {
  const allowedPaths = testPaths.filter(filteringFunction); // ["path1.spec.js", "path2.spec.js", etc]

  return {
    filtered: allowedPaths,
  };
};

`--findRelatedTests `

Find and run the tests that cover a space separated list of source files that were passed in as arguments. Useful for pre-commit hook integration to run the minimal amount of tests necessary. Can be used together with --coverage to include a test coverage for the source files, no duplicate --collectCoverageFrom arguments needed.

`--forceExit`

Force Jest to exit after all tests have completed running. This is useful when resources set up by test code cannot be adequately cleaned up.

:::caution

This feature is an escape-hatch. If Jest doesn't exit at the end of a test run, it means external resources are still being held on to or timers are still pending in your code. It is advised to tear down external resources after each test to make sure Jest can shut down cleanly. You can use --detectOpenHandles to help track it down.

:::

`--help`

Show the help information, similar to this page.

`--ignoreProjects ... `

Ignore the tests of the specified projects. Jest uses the attribute displayName in the configuration to identify each project. If you use this option, you should provide a displayName to all your projects.

`--injectGlobals`

Insert Jest's globals (expect, test, describe, beforeEach etc.) into the global environment. If you set this to false, you should import from @jest/globals, e.g.

ts
import {expect, jest, test} from '@jest/globals';

jest.useFakeTimers();

test('some test', () => {
  expect(Date.now()).toBe(0);
});

:::note

This option is only supported using the default jest-circus test runner.

:::

`--json`

Prints the test results in JSON. This mode will send all other test output and user messages to stderr.

`--lastCommit`

Run all tests affected by file changes in the last commit made. Behaves similarly to --onlyChanged.

`--listTests`

Lists all test files that Jest will run given the arguments, and exits.

`--logHeapUsage`

Logs the heap usage after every test. Useful to debug memory leaks. Use together with --runInBand and --expose-gc in node.

`--maxConcurrency=`

Prevents Jest from executing more than the specified amount of tests at the same time. Only affects tests that use test.concurrent.

`--maxWorkers=|`

Alias: -w. Specifies the maximum number of workers the worker-pool will spawn for running tests. In single run mode, this defaults to the number of the cores available on your machine minus one for the main thread. In watch mode, this defaults to half of the available cores on your machine to ensure Jest is unobtrusive and does not grind your machine to a halt. It may be useful to adjust this in resource limited environments like CIs but the defaults should be adequate for most use-cases.

For environments with variable CPUs available, you can use percentage based configuration: --maxWorkers=50%

`--noStackTrace`

Disables stack trace in test results output.

`--notify`

Activates native OS notifications for test results. Good for when you don't want your consciousness to be able to focus on anything except JavaScript testing. To display the notifications Jest needs the node-notifier package, which must be installed separately.

`--onlyChanged`

Alias: -o. Attempts to identify which tests to run based on which files have changed in the current repository. Only works if you're running tests in a git/hg repository at the moment and requires a static dependency graph (ie. no dynamic requires).

`--onlyFailures`

Alias: -f. Run tests that failed in the previous execution.

`--openHandlesTimeout=`

When --detectOpenHandles and --forceExit are disabled, Jest will print a warning if the process has not exited cleanly after this number of milliseconds. A value of 0 disables the warning. Defaults to 1000.

`--outputFile=`

Write test results to a file when the --json option is also specified. The returned JSON structure is documented in testResultsProcessor.

`--passWithNoTests`

Allows the test suite to pass when no files are found.

`--projects ... `

Run tests from one or more projects, found in the specified paths; also takes path globs. This option is the CLI equivalent of the projects configuration option.

:::note

If configuration files are found in the specified paths, all projects specified within those configuration files will be run.

:::

`--randomize`

Shuffle the order of the tests within a file. The shuffling is based on the seed. See --seed=<num> for more info.

Seed value is displayed when this option is set. Equivalent to setting the CLI option --showSeed.

bash
jest --randomize --seed 1234

:::note

This option is only supported using the default jest-circus test runner.

:::

`--reporters`

Run tests with specified reporters. Reporter options are not available via CLI. Example with multiple reporters:

jest --reporters="default" --reporters="jest-junit"

`--resetMocks`

Automatically reset mock state before every test. Equivalent to calling jest.resetAllMocks() before each test. This will lead to any mocks having their fake implementations removed but does not restore their initial implementation.

`--restoreMocks`

Automatically restore mock state and implementation before every test. Equivalent to calling jest.restoreAllMocks() before each test. This will lead to any mocks having their fake implementations removed and restores their initial implementation.

`--roots`

A list of paths to directories that Jest should use to search for files in.

`--runInBand`

Alias: -i. Run all tests serially in the current process, rather than creating a worker pool of child processes that run tests. This can be useful for debugging.

`--runTestsByPath`

Run only the tests that were specified with their exact paths. This avoids converting them into a regular expression and matching it against every single file.

For example, given the following file structure:

bash
__tests__
└── t1.test.js # test
└── t2.test.js # test

When ran with a pattern, no test is found:

bash
jest --runTestsByPath __tests__/t

Output:

bash
No tests found

However, passing an exact path will execute only the given test:

bash
jest --runTestsByPath __tests__/t1.test.js

Output:

bash
PASS __tests__/t1.test.js

:::tip

The default regex matching works fine on small runs, but becomes slow if provided with multiple patterns and/or against a lot of tests. This option replaces the regex matching logic and by that optimizes the time it takes Jest to filter specific test files.

:::

`--seed=`

Sets a seed value that can be retrieved in a test file via jest.getSeed(). The seed value must be between -0x80000000 and 0x7fffffff inclusive (-2147483648 (-(2 ** 31)) and 2147483647 (2 ** 31 - 1) in decimal).

bash
jest --seed=1324

:::tip

If this option is not specified Jest will randomly generate the value. You can use the --showSeed flag to print the seed in the test report summary.

Jest uses the seed internally for shuffling the order in which test suites are run. If the --randomize option is used, the seed is also used for shuffling the order of tests within each describe block. When dealing with flaky tests, rerunning with the same seed might help reproduce the failure.

:::

`--selectProjects ... `

Run the tests of the specified projects. Jest uses the attribute displayName in the configuration to identify each project. If you use this option, you should provide a displayName to all your projects.

`--setupFilesAfterEnv ... `

A list of paths to modules that run some code to configure or to set up the testing framework before each test file. Beware that files imported by the setup scripts will not be mocked during testing.

`--shard`

The test suite shard to execute in a format of (?<shardIndex>\d+)/(?<shardCount>\d+).

shardIndex describes which shard to select while shardCount controls the number of shards the suite should be split into.

shardIndex and shardCount have to be 1-based, positive numbers, and shardIndex has to be lower than or equal to shardCount.

When shard is specified the configured testSequencer has to implement a shard method.

For example, to split the suite into three shards, each running one third of the tests:

text
jest --shard=1/3
jest --shard=2/3
jest --shard=3/3

`--showConfig`

Print your Jest config and then exits.

`--showSeed`

Prints the seed value in the test report summary. See --seed=<num> for the details.

Can also be set in configuration. See showSeed.

`--silent`

Prevent tests from printing messages through the console.

`--testEnvironmentOptions=`

A JSON string with options that will be passed to the testEnvironment. The relevant options depend on the environment.

`--testLocationInResults`

Adds a location field to test results. Useful if you want to report the location of a test in a reporter.

:::note

line is 1-indexed. column is 1-indexed with the default jest-circus runner, but 0-indexed with jest-jasmine2. Both will be 1-indexed in Jest 31, matching the positions V8 reports in a stack trace and through CallSite.

json
{
  "column": 4,
  "line": 5
}

:::

`--testMatch glob1 ... globN`

The glob patterns Jest uses to detect test files. Please refer to the testMatch configuration for details.

`--testNamePattern=`

Alias: -t. Run only tests with a name that matches the regex. For example, suppose you want to run only tests related to authorization which will have names like 'GET /api/posts with auth', then you can use jest -t=auth.

:::tip

The regex is matched against the full name, which is a combination of the test name and all its surrounding describe blocks.

:::

`--testPathIgnorePatterns=|[array]`

A single or array of regexp pattern strings that are tested against all tests paths before executing the test. Contrary to --testPathPatterns, it will only run those tests with a path that does not match with the provided regexp expressions.

To pass as an array use escaped parentheses and space delimited regexps such as \(/node_modules/ /tests/e2e/\). Alternatively, you can omit parentheses by combining regexps into a single regexp like /node_modules/|/tests/e2e/. These two examples are equivalent.

`--testPathPatterns=`

A regexp pattern string that is matched against all tests paths before executing the test. On Windows, you will need to use / as a path separator or escape \ as \\.

`--testRunner=`

Lets you specify a custom test runner.

`--testSequencer=`

Lets you specify a custom test sequencer. Please refer to the testSequencer configuration for details.

`--testTimeout=`

Default timeout of a test in milliseconds. Default value: 5000.

`--updateSnapshot`

Alias: -u. Use this flag to re-record every snapshot that fails during this test run. Can be used together with a test suite pattern or with --testNamePattern to re-record snapshots.

`--useStderr`

Divert all output to stderr.

`--verbose`

Display individual test results with the test suite hierarchy.

`--version`

Alias: -v. Print the version and exit.

`--waitForUnhandledRejections`

Gives one event loop turn to handle rejectionHandled, uncaughtException or unhandledRejection.

Without this flag Jest may report false-positive errors (e.g. actually handled rejection reported) or not report actually unhandled rejection (or report it for different test case).

This option may add a noticeable overhead for fast test suites.

`--watch`

Watch files for changes and rerun tests related to changed files. If you want to re-run all tests when a file has changed, use the --watchAll option instead.

:::tip

Use --no-watch (or --watch=false) to explicitly disable the watch mode if it was enabled using --watch. In most CI environments, this is automatically handled for you.

:::

`--watchAll`

Watch files for changes and rerun all tests when something changes. If you want to re-run only the tests that depend on the changed files, use the --watch option.

:::tip

Use --no-watchAll (or --watchAll=false) to explicitly disable the watch mode if it was enabled using --watchAll. In most CI environments, this is automatically handled for you.

:::

`--watchman`

Whether to use watchman for file crawling. Defaults to true. Disable using --no-watchman.

`--workerGracefulExitTimeout=`

Timeout in milliseconds for worker processes to exit gracefully after tests complete. Workers that do not exit in time are force-killed. Default: 500.

`--workerThreads`

Whether to use worker threads for parallelization. Child processes are used by default.

:::caution

This is experimental feature. See the workerThreads configuration option for more details.

:::

File: docs/CodeTransformation.md

id: code-transformation title: Code Transformation

Jest runs the code in your project as JavaScript, but if you use some syntax not supported by Node out of the box (such as JSX, TypeScript, Vue templates) then you'll need to transform that code into plain JavaScript, similar to what you would do when building for browsers.

Jest supports this via the transform configuration option.

A transformer is a module that provides a method for transforming source files. For example, if you wanted to be able to use a new language feature in your modules or tests that aren't yet supported by Node, you might plug in a code preprocessor that would transpile a future version of JavaScript to a current one.

Jest will cache the result of a transformation and attempt to invalidate that result based on a number of factors, such as the source of the file being transformed and changing configuration.

Defaults

Jest ships with one transformer out of the box – babel-jest. It will load your project's Babel configuration and transform any file matching the /\.[jt]sx?$/ RegExp (in other words, any .js, .jsx, .ts or .tsx file). In addition, babel-jest will inject the Babel plugin necessary for mock hoisting talked about in ES Module mocking.

:::note

By default, babel-jest includes babel-preset-jest. You can disable this behavior by specifying excludeJestPreset: true to babel-jest. Note that this will also stop hoisting jest.mock, which may break your tests.

json
"transform": {
  "\\.[jt]sx?$": ["babel-jest", { "excludeJestPreset": true }],
}

:::

:::tip

Remember to include the default babel-jest transformer explicitly, if you wish to use it alongside with additional code preprocessors:

json
"transform": {
  "\\.[jt]sx?$": "babel-jest",
  "\\.css$": "some-css-transformer",
}

:::

Writing custom transformers

You can write your own transformer. The API of a transformer is as follows:

text
/* Detailed source-code truncated for AI context efficiency. */

:::note

The definitions above were trimmed down for brevity. Full code can be found in Jest repo on GitHub (remember to choose the right tag/commit for your version of Jest).

:::

There are a couple of ways you can import code into Jest - using Common JS (require) or ECMAScript Modules (import - which exists in static and dynamic versions). Jest passes files through code transformation on demand (for instance when a require or import is evaluated). This process, also known as "transpilation", might happen synchronously (in the case of require), or asynchronously (in the case of import or import(), the latter of which also works from Common JS modules). For this reason, the interface exposes both pairs of methods for asynchronous and synchronous processes: process{Async} and getCacheKey{Async}. The latter is called to figure out if we need to call process{Async} at all.

Asynchronous transpilation can fall back to the synchronous process call if processAsync is unimplemented, but synchronous transpilation cannot use the asynchronous processAsync call. If your codebase is ESM only, implementing the async variants are sufficient. Otherwise, if any code is loaded through require (including createRequire from within ESM), then you need to implement the synchronous process variant.

Be aware that node_modules is not transpiled with default config, the transformIgnorePatterns setting must be modified in order to do so.

Semi-related to this are the supports flags we pass (see CallerTransformOptions above), but those should be used within the transform to figure out if it should return ESM or CJS, and has no direct bearing on sync vs async

Though not required, we highly recommend implementing getCacheKey as well, so we do not waste resources transpiling when we could have read its previous result from disk. You can use @jest/create-cache-key-function to help implement it.

Instead of having your custom transformer implement the Transformer interface directly, you can choose to export createTransformer, a factory function to dynamically create transformers. This is to allow having a transformer config in your jest config.

:::note

ECMAScript module support is indicated by the passed in supports* options. Specifically supportsDynamicImport: true means the transformer can return import() expressions, which is supported by both ESM and CJS. If supportsStaticESM: true it means top level import statements are supported and the code will be interpreted as ESM and not CJS. See Node's docs for details on the differences.

:::

:::tip

Make sure process{Async} method returns source map alongside with transformed code, so it is possible to report line information accurately in code coverage and test errors. Inline source maps also work but are slower.

During the development of a transformer it can be useful to run Jest with --no-cache to frequently delete cache.

:::

Examples

TypeScript with type checking

While babel-jest by default will transpile TypeScript files, Babel will not verify the types. If you want that you can use ts-jest.

Transforming images to their path

Importing images is a way to include them in your browser bundle, but they are not valid JavaScript. One way of handling it in Jest is to replace the imported value with its filename.

js title="filetransformer.js"
const path = require('path');

module.exports = {
  process(sourceText, sourcePath, options) {
    return {
      code: `module.exports = ${JSON.stringify(path.basename(sourcePath))};`,
    };
  },
};
js title="jest.config.js"
module.exports = {
  transform: {
    '\\.(jpg|jpeg|png|gif|eot|otf|webp|svg|ttf|woff|woff2|mp4|webm|wav|mp3|m4a|aac|oga)$':
      '<rootDir>/fileTransformer.js',
  },
};

File: docs/DynamoDB.md

id: dynamodb title: Using with DynamoDB

With the Global Setup/Teardown and Async Test Environment APIs, Jest can work smoothly with DynamoDB.

Use jest-dynamodb Preset

Jest DynamoDB provides all required configuration to run your tests using DynamoDB.

  1. First, install @shelf/jest-dynamodb
bash npm2yarn
npm install --save-dev @shelf/jest-dynamodb
  1. Specify preset in your Jest configuration:
json
{
  "preset": "@shelf/jest-dynamodb"
}
  1. Create jest-dynamodb-config.js and define DynamoDB tables

See Create Table API

js
module.exports = {
  tables: [
    {
      TableName: `files`,
      KeySchema: [{AttributeName: 'id', KeyType: 'HASH'}],
      AttributeDefinitions: [{AttributeName: 'id', AttributeType: 'S'}],
      ProvisionedThroughput: {ReadCapacityUnits: 1, WriteCapacityUnits: 1},
    },
    // etc
  ],
};
  1. Configure DynamoDB client
js
const {DocumentClient} = require('aws-sdk/clients/dynamodb');

const isTest = process.env.JEST_WORKER_ID;
const config = {
  convertEmptyValues: true,
  ...(isTest && {
    endpoint: 'localhost:8000',
    sslEnabled: false,
    region: 'local-env',
  }),
};

const ddb = new DocumentClient(config);
  1. Write tests
js
it('should insert item into table', async () => {
  await ddb
    .put({TableName: 'files', Item: {id: '1', hello: 'world'}})
    .promise();

  const {Item} = await ddb.get({TableName: 'files', Key: {id: '1'}}).promise();

  expect(Item).toEqual({
    id: '1',
    hello: 'world',
  });
});

There's no need to load any dependencies.

See documentation for details.

File: docs/ECMAScriptModules.md

id: ecmascript-modules title: ECMAScript Modules

:::caution

Jest ships with experimental support for ECMAScript Modules (ESM).

The implementation may have bugs and lack features. For the latest status check out the issue and the label on the issue tracker.

Also note that the APIs Jest uses to implement ESM support are still considered experimental by Node (as of version 18.8.0).

:::

With the warnings out of the way, this is how you activate ESM support in your tests.

  1. Ensure you either disable code transforms by passing transform: {} or otherwise configure your transformer to emit ESM rather than the default CommonJS (CJS).

  2. Execute node with --experimental-vm-modules, e.g. node --experimental-vm-modules node_modules/jest/bin/jest.js or NODE_OPTIONS="$NODE_OPTIONS --experimental-vm-modules" npx jest etc.

    On Windows, you can use cross-env to be able to set environment variables.

    If you use Yarn, you can use yarn node --experimental-vm-modules $(yarn bin jest). This command will also work if you use Yarn Plug'n'Play.

    If your codebase includes ESM imports from *.wasm files, you do not need to pass --experimental-wasm-modules to node. Current implementation of WebAssembly imports in Jest relies on experimental VM modules, however, this may change in the future.

  3. Beyond that, we attempt to follow node's logic for activating "ESM mode" (such as looking at type in package.json or .mjs files), see their docs for details.

  4. If you want to treat other file extensions (such as .jsx or .ts) as ESM, please use the extensionsToTreatAsEsm option.

Differences between ESM and CommonJS

Most of the differences are explained in Node's documentation, but in addition to the things mentioned there, Jest injects a special variable into all executed files - the jest object. To access this object in ESM, you need to import it from the @jest/globals module or use import.meta.

js
import {jest} from '@jest/globals';

jest.useFakeTimers();

// etc.

// alternatively
import.meta.jest.useFakeTimers();

// jest === import.meta.jest => true

`require()` of ESM

On Node v24.9 and later, Jest supports require()-ing an ES module from CJS code, mirroring Node's own require(esm).

js title="main.test.cjs"
const {value, default: defaultExport} = require('./esm-module.mjs');

Calling require() on an ESM file with top-level await (or whose graph contains TLA) throws ERR_REQUIRE_ASYNC_MODULE. Use await import(...) for those files.

Packages resolve through the require and module-sync conditions, as they do in Node. A package that exposes its ESM entry point under module-sync can therefore be require()d, and one that exposes it only under import cannot - Node refuses that too, with ERR_PACKAGE_PATH_NOT_EXPORTED. A module-sync entry point whose graph contains top-level await throws ERR_REQUIRE_ASYNC_MODULE.

jest.mock does not apply when the resolved file is ESM - jest.mock is for CJS targets. To mock an ESM file you require(), register the mock via jest.unstable_mockModule (the mock applies to transitive dependencies the loaded ESM imports).

On Node versions older than v24.9, require() of an ESM file still throws ERR_REQUIRE_ESM.

Divergences from Node

Jest's module system diverges from Node's in a few places:

  • In a graph that mixes ESM and CJS, the CJS dependencies execute while the graph is built, so a CJS module can run earlier relative to its ESM siblings than it would in Node.
  • The named exports of a CJS module imported from ESM are a superset of Node's: keys present on module.exports after evaluation are exposed in addition to what static analysis finds.
  • Writes to and deletes from require.cache are silently ignored.
  • The static members of require('module') (such as Module._resolveFilename) come from the host Node, not from Jest's module system.
  • require() of an ES module that is part of a graph currently being loaded throws ERR_REQUIRE_CYCLE_MODULE even when the required module is not an ancestor of the requiring module.
  • The 'module.exports' named export of an imported CJS module is exposed on every Node version, including versions older than v23 where Node itself does not provide it.
  • Importing JSON without with {type: 'json'} emits a warning instead of throwing. This becomes an error in a future major version.
  • An application/wasm data: URI requires the ;base64 parameter and reports a descriptive error without it, where Node hands the percent-decoded text to WebAssembly and fails with CompileError.
  • A bare core specifier with a query or fragment (import 'fs?q') throws ERR_UNKNOWN_BUILTIN_MODULE, where Node treats the whole string as a package name and fails with ERR_MODULE_NOT_FOUND. The node:-prefixed form throws the same error in both.
  • Stack traces show file paths, not file:// URLs.

Module mocking in ESM

Since ESM evaluates static import statements before looking at the code, the hoisting of jest.mock calls that happens in CJS won't work for ESM. To mock modules in ESM, you need to use require or dynamic import() after jest.mock calls to load the mocked modules - the same applies to modules which load the mocked modules.

ESM mocking is supported through jest.unstable_mockModule. As the name suggests, this API is still work in progress, please follow this issue for updates.

The usage of jest.unstable_mockModule is essentially the same as jest.mock with two differences: the factory function is required and it can be sync or async:

js
import {jest} from '@jest/globals';

jest.unstable_mockModule('node:child_process', () => ({
  execSync: jest.fn(),
  // etc.
}));

const {execSync} = await import('node:child_process');

// etc.

Module unmocking in ESM

js title="esm-module.mjs"
export default () => {
  return 'default';
};

export const namedFn = () => {
  return 'namedFn';
};
js title="esm-module.test.mjs"
import {jest, test} from '@jest/globals';

test('test esm-module', async () => {
  jest.unstable_mockModule('./esm-module.js', () => ({
    default: () => 'default implementation',
    namedFn: () => 'namedFn implementation',
  }));

  const mockModule = await import('./esm-module.js');

  console.log(mockModule.default()); // 'default implementation'
  console.log(mockModule.namedFn()); // 'namedFn implementation'

  jest.unstable_unmockModule('./esm-module.js');

  const originalModule = await import('./esm-module.js');

  console.log(originalModule.default()); // 'default'
  console.log(originalModule.namedFn()); // 'namedFn'

  /* !!! WARNING !!! Don`t override */
  jest.unstable_mockModule('./esm-module.js', () => ({
    default: () => 'default override implementation',
    namedFn: () => 'namedFn override implementation',
  }));

  const mockModuleOverride = await import('./esm-module.js');

  console.log(mockModuleOverride.default()); // 'default implementation'
  console.log(mockModuleOverride.namedFn()); // 'namedFn implementation'
});

Mocking CJS modules

For mocking CJS modules, you should continue to use jest.mock. See the example below:

js title="main.cjs"
const {BrowserWindow, app} = require('electron');

// etc.

module.exports = {example};
js title="main.test.cjs"
import {createRequire} from 'node:module';
import {jest} from '@jest/globals';

const require = createRequire(import.meta.url);

jest.mock('electron', () => ({
  app: {
    on: jest.fn(),
    whenReady: jest.fn(() => Promise.resolve()),
  },
  BrowserWindow: jest.fn().mockImplementation(() => ({
    // partial mocks.
  })),
}));

const {BrowserWindow} = require('electron');
const exported = require('./main.cjs');

// alternatively
const {BrowserWindow} = (await import('electron')).default;
const exported = await import('./main.cjs');

// etc.

Explore Related Technologies & Topics

View All 9,111+ Repositories →

Discover similar high-velocity repositories, agent skills, and OpenAPI specifications across the ecosystem.

#easy Browse easy catalog → #expectation Browse expectation catalog → #facebook Browse facebook catalog → #immersive Browse immersive catalog → #javascript Browse javascript catalog → #painless Browse painless catalog → ⚡ MCP Servers Model Context Protocol → 🧠 Agent Skills Prompt & rule files → 🔌 OpenAPI Specs REST & Swagger schemas →