翻译自：https://jestjs.io/docs/zh-Hans/configuration
最新更新：2020/01

Jest的配置可以通过package.json或是jest.config.js文件来配置，支持多种文件后缀，格式
如下：

--config <path/to/file.js|cjs|mjs|json>

想要在package.json中配置的可以引入jest字段：

{
  "name": "my-project",
  "jest": {
    "verbose": true
  }
}

选项

这些选项可以让你控制Jest的行为。虽然Jest的设计初衷就是希望能够零配置实现测试，但有时候你需要更强大的配置能力。

Jest提供了默认选项，方便你在必要时扩展他们：

// jest.config.js
const {defaults} = require('jest-config');
module.exports = {
  // ...
  moduleFileExtensions: [...defaults.moduleFileExtensions, 'ts', 'tsx'],
  // ...
};

API列表

automock [boolean]

默认值︰false

这个选项告诉Jest所有的导入模块都自动mock下.

示例：

// utils.js
export default {
  authorize: () => {
    return 'token';
  },
  isAuthorized: secret => secret === 'wizard',
};

//__tests__/automocking.test.js
import utils from '../utils';

test('if utils mocked automatically', () => {
  // Public methods of `utils` are now mock functions
  expect(utils.authorize.mock).toBeTruthy();
  expect(utils.isAuthorized.mock).toBeTruthy();

  // You can provide them with your own implementation
  // or pass the expected return value
  utils.authorize.mockReturnValue('mocked_token');
  utils.isAuthorized.mockReturnValue(true);

  expect(utils.authorize()).toBe('mocked_token');
  expect(utils.isAuthorized('not_wizard')).toBeTruthy();
});

注意：node modules当源文件下面有mocks目录时会自动执行mock。核心模块，例如fs，是不会默认mock的，需要手动设置下：jest.mock('fs')

bail [number | boolean]

Default: 0

Jest默认将所有测试产生的信息都通过console显示，bail选项可以让你配置jest在经历几次失败后停止运行测试，设置为true跟设置1是一样的。

browser [boolean]

默认值︰false

当解析模块时，是否遵循在 package.json 中的 Browserify 的 "browser" 字段。 有些模块会导出不一样的版本，这取决于你是在 Node 还是在一个浏览器中进行操作。

cacheDirectory [string]

默认值︰ "/tmp/<path>"

Jest用来储存依赖信息缓存的目录。
Jest 尝试去扫描你的依赖树一次（前期）并且把依赖树缓存起来，其目的就是抹去某些在运行测试时需要进行的文件系统排序。 这一配置选项让你可以自定义Jest将缓存数据储存在磁盘的那个位置。

clearMocks [boolean]

默认值︰false

在每个测试前自动清理mock的调用和实例instance。等效于在每个test之前调用jest.clearAllMocks，但不会删除已经有的mock实现。

collectCoverage [boolean]

默认值︰false

指出是否收集测试时的覆盖率信息。 由于要带上覆盖率搜集语句重新访问所有执行过的文件，这可能会让你的测试执行速度被明显减慢。

collectCoverageFrom [array]

默认值：undefined

参数是glob patterns 的列表，表明哪些集合的文件是需要收集的。如果文件匹配了，那么就会被收集作为coverage的基数，哪怕这个文件没有测试的用例。

示例：

{
  "collectCoverageFrom": [
    "**/*.{js,jsx}",
    "!**/node_modules/**",
    "!**/vendor/**"
  ]
}

上面的例子中搜索在rootDir下面所有的以js或是jsx为后缀的文件，同时派出node_modules
和vendor目录下的文件。

注意：该选项要求 collectCoverage 被设成true，或者通过 --coverage 参数来调用 Jest。

coverageDirectory [string]

默认值：undefined

Jest输出覆盖信息文件的目录。

coveragePathIgnorePatterns [array<string>]

默认值︰["node_modules"]

排除出coverage的文件列表， 这些pattern string默认匹配全路径，可以添加<rootDir>token来放置有些系统环境里面把你的覆盖文件遗漏了。例如：["<rootDir>/build/", "<rootDir>/node_modules/"].

coverageProvider [string]

声明到底用哪个provider来用于指导代码的覆盖测试，允许的参数有babel (default) 或是 v8。

注意：v8还处于试验阶段，相比babel的配置可能会有一些瑕疵。

coverageReporters [array<string>]

Default: ["json", "lcov", "text", "clover"]

列出包含reporter名字的列表，而Jest会用他们来生成覆盖报告。至于reporter有哪些，请参考：istanbul reporter .

coverageThreshold [object]

默认值：undefined

这个阈值是作为覆盖结构的最小阈值来设置的。可以被设置为global
glob,或是目录及文件路径。如果没有达到阈值，Jest 执行测试时将会失败。 如果给了个正数，那么就表示是最小的百分比值，如果给了个负数就表示最大的未被覆盖的允许值。

举个例子，下面的配置我们设置了branch分支数和函数覆盖率小于80%，和10%的上限未覆盖statements

{
  ...
  "jest": {
    "coverageThreshold": {
      "global": {
        "branches": 80,
        "functions": 80,
        "lines": 80,
        "statements": -10
      }
    }
  }
}

dependencyExtractor [string]

默认值：undefined

这个选项允许特定依赖提取器的使用，必须满足是一个node module，同时导出的object中包含extract函数。

例如：

const fs = require('fs');
const crypto = require('crypto');

module.exports = {
  extract(code, filePath, defaultExtract) {
    const deps = defaultExtract(code, filePath);
    // Scan the file and add dependencies in `deps` (which is a `Set`)
    return deps;
  },
  getCacheKey() {
    return crypto
      .createHash('md5')
      .update(fs.readFileSync(__filename))
      .digest('hex');
  },
};

extract 函数应该要返回一个code里面依赖项，并且返回结果是可以遍历的.(例如 Array, Set, etc.) 。

同时module还要包含一个getCacheKey 函数来生成一个缓存的key，用于决定逻辑是否变更。

displayName [string, object]

默认值：undefined

允许在测试允许的时候打印显示标签。这在有多个repo和多个jest配置文件的时候很好用。

module.exports = {
  displayName: 'CLIENT',
};

或

module.exports = {
  displayName: {
    name: 'CLIENT',
    color: 'blue',
  },
};

errorOnDeprecated [boolean]

默认值︰false

针对过期的API抛出提示性的错误信息。

extraGlobals [array<string>]

默认值：undefined

Test files run inside a vm, which slows calls to global context properties (e.g. Math). With this option you can specify extra properties to be defined inside the vm for faster lookups.

For example, if your tests call Math often, you can pass it by setting extraGlobals.

{
  ...
  "jest": {
    "extraGlobals": ["Math"]
  }
}

forceCoverageMatch [array<string>]

Default: ['']

Test files are normally ignored from collecting code coverage. With this option, you can overwrite this behavior and include otherwise ignored files in code coverage.

For example, if you have tests in source files named with .t.js extension as following:

// sum.t.js

export function sum(a, b) {
  return a + b;
}

if (process.env.NODE_ENV === 'test') {
  test('sum', () => {
    expect(sum(1, 2)).toBe(3);
  });
}

你可以通过设置 forceCoverageMatch 从这些文件中收集覆盖率。

{
  ...
  "jest": {
    "forceCoverageMatch": ["**/*.t.js"]
  }
}

globals [object]

默认值：{}

一组全局变量，在所有测试环境下都可以访问。

例如，下面这段代码将为所有测试环境创建一个值为true的全局变量__DEV__：

{
  ...
  "jest": {
    "globals": {
      "__DEV__": true
    }
  }
}

注意，如果你在这指定了一个全局引用值（例如，对象或者数组），之后在测试运行中有些代码改变了这个被引用的值，这个改动对于其他测试不会生效。 In addition the globals object must be json-serializable, so it can't be used to specify global functions. 要实现这种功能，应该使用 setupFiles。

globalSetup [string]

默认值：undefined

This option allows the use of a custom global setup module which exports an async function that is triggered once before all test suites. This function gets Jest's globalConfig object as a parameter.

Note: A global setup module configured in a project (using multi-project runner) will be triggered only when you run at least one test from this project.

Note: Any global variables that are defined through globalSetup can only be read in globalTeardown. You cannot retrieve globals defined here in your test suites.

Note: While code transformation is applied to the linked setup-file, Jest will not transform any code in node_modules. This is due to the need to load the actual transformers (e.g. babel or typescript) to perform transformation.

示例：

// setup.js
module.exports = async () => {
  // ...
  // Set reference to mongod in order to close the server during teardown.
  global.__MONGOD__ = mongod;
};

// teardown.js
module.exports = async function() {
  await global.__MONGOD__.stop();
};

globalTeardown [string]

默认值：undefined

This option allows the use of a custom global teardown module which exports an async function that is triggered once after all test suites. This function gets Jest's globalConfig object as a parameter.

Note: A global teardown module configured in a project (using multi-project runner) will be triggered only when you run at least one test from this project.

Note: The same caveat concerning transformation of node_modules as for globalSetup applies to globalTeardown.

maxConcurrency [number]

Default: 5

A number limiting the number of tests that are allowed to run at the same time when using test.concurrent. Any test above this limit will be queued and executed once a slot is released.

moduleDirectories [array<string>]

默认值︰["node_modules"]

An array of directory names to be searched recursively up from the requiring module's location. Setting this option will override the default, if you wish to still search node_modules for packages include it along with any other options: ["node_modules", "bower_components"]

moduleFileExtensions [array<string>]

Default: ["js", "json", "jsx", "ts", "tsx", "node"]

An array of file extensions your modules use. If you require modules without specifying a file extension, these are the extensions Jest will look for, in left-to-right order.

We recommend placing the extensions most commonly used in your project on the left, so if you are using TypeScript, you may want to consider moving "ts" and/or "tsx" to the beginning of the array.

moduleNameMapper [object<string, string>]

默认值︰null

A map from regular expressions to module names that allow to stub out resources, like images or styles with a single module.

Modules that are mapped to an alias are unmocked by default, regardless of whether automocking is enabled or not.

Use <rootDir> string token to refer to rootDir value if you want to use file paths.

Additionally, you can substitute captured regex groups using numbered backreferences.

示例：

{
  "moduleNameMapper": {
    "^image![a-zA-Z0-9$_-]+$": "GlobalImageStub",
    "^[./a-zA-Z0-9$_-]+\\.png$": "<rootDir>/RelativeImageStub.js",
    "module_name_(.*)": "<rootDir>/substituted_module_$1.js"
  }
}

The order in which the mappings are defined matters. Patterns are checked one by one until one fits. The most specific rule should be listed first.

Note: If you provide module name without boundaries ^$ it may cause hard to spot errors. E.g. relay will replace all modules which contain relay as a substring in its name: relay, react-relay and graphql-relay will all be pointed to your stub.

modulePathIgnorePatterns [array<string>]

默认值：[]

An array of regexp pattern strings that are matched against all module paths before those paths are to be considered 'visible' to the module loader. If a given module's path matches any of the patterns, it will not be require()-able in the test environment.

These pattern strings match against the full path. Use the <rootDir> string token to include the path to your project's root directory to prevent it from accidentally ignoring all of your files in different environments that may have different root directories. Example: ["<rootDir>/build/"].

modulePaths [array<string>]

默认值：[]

An alternative API to setting the NODE_PATH env variable, modulePaths is an array of absolute paths to additional locations to search when resolving modules. Use the <rootDir> string token to include the path to your project's root directory. Example: ["<rootDir>/app/"].

notify [boolean]

默认值︰false

Activates notifications for test results.

notifyMode [string]

Default: failure-change

Specifies notification mode. Requires notify: true.

Modes

• always: always send a notification.
• failure: send a notification when tests fail.
• success: send a notification when tests pass.
• change: send a notification when the status changed.
• success-change: send a notification when tests pass or once when it fails.
• failure-change: send a notification when tests fail or once when it passes.

preset [string]

默认值：undefined

A preset that is used as a base for Jest's configuration. A preset should point to an npm module that has a jest-preset.json or jest-preset.js file at the root.

For example, this preset foo-bar/jest-preset.js will be configured as follows:

{
  "preset": "foo-bar"
}

Presets may also be relative filesystem paths.

{
  "preset": "./node_modules/foo-bar/jest-preset.js"
}

prettierPath [string]

Default: 'prettier'

Sets the path to the prettier node module used to update inline snapshots.

projects [array<string | ProjectConfig>]

默认值：undefined

When the projects configuration is provided with an array of paths or glob patterns, Jest will run tests in all of the specified projects at the same time. This is great for monorepos or when working on multiple projects at the same time.

{
  "projects": ["<rootDir>", "<rootDir>/examples/*"]
}

This example configuration will run Jest in the root directory as well as in every folder in the examples directory. You can have an unlimited amount of projects running in the same Jest instance.

The projects feature can also be used to run multiple configurations or multiple runners. For this purpose you can pass an array of configuration objects. For example, to run both tests and ESLint (via jest-runner-eslint) in the same invocation of Jest:

{
  "projects": [
    {
      "displayName": "test"
    },
    {
      "displayName": "lint",
      "runner": "jest-runner-eslint",
      "testMatch": ["<rootDir>/**/*.js"]
    }
  ]
}

Note: When using multi project runner, it's recommended to add a displayName for each project. This will show the displayName of a project next to its tests.

reporters [array<moduleName | [moduleName, options]>]

默认值：undefined

Use this configuration option to add custom reporters to Jest. A custom reporter is a class that implements onRunStart, onTestStart, onTestResult, onRunComplete methods that will be called when any of those events occurs.

If custom reporters are specified, the default Jest reporters will be overridden. To keep default reporters, default can be passed as a module name.

This will override default reporters:

{
  "reporters": ["<rootDir>/my-custom-reporter.js"]
}

This will use custom reporter in addition to default reporters that Jest provides:

{
  "reporters": ["default", "<rootDir>/my-custom-reporter.js"]
}

Additionally, custom reporters can be configured by passing an options object as a second argument:

{
  "reporters": [
    "default",
    ["<rootDir>/my-custom-reporter.js", {"banana": "yes", "pineapple": "no"}]
  ]
}

Custom reporter modules must define a class that takes a GlobalConfig and reporter options as constructor arguments:

Example reporter:

// my-custom-reporter.js
class MyCustomReporter {
  constructor(globalConfig, options) {
    this._globalConfig = globalConfig;
    this._options = options;
  }

  onRunComplete(contexts, results) {
    console.log('Custom reporter output:');
    console.log('GlobalConfig: ', this._globalConfig);
    console.log('Options: ', this._options);
  }
}

module.exports = MyCustomReporter;
// or export default MyCustomReporter;

Custom reporters can also force Jest to exit with non-0 code by returning an Error from getLastError() methods

class MyCustomReporter {
  // ...
  getLastError() {
    if (this._shouldFail) {
      return new Error('my-custom-reporter.js reported an error');
    }
  }
}

For the full list of methods and argument types see Reporter interface in packages/jest-reporters/src/types.ts

resetMocks [boolean]

默认值︰false

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.

resetModules [boolean]

默认值︰false

By default, each test file gets its own independent module registry. Enabling resetModules goes a step further and resets the module registry before running each individual test. This is useful to isolate modules for every test so that local module state doesn't conflict between tests. This can be done programmatically using jest.resetModules().

resolver [string]

默认值：undefined

This option allows the use of a custom resolver. This resolver must be a node module that exports a function expecting a string as the first argument for the path to resolve and an object with the following structure as the second argument:

{
  "basedir": string,
  "browser": bool,
  "defaultResolver": "function(request, options)",
  "extensions": [string],
  "moduleDirectory": [string],
  "paths": [string],
  "rootDir": [string]
}

The function should either return a path to the module that should be resolved or throw an error if the module can't be found.

Note: the defaultResolver passed as options is the jest default resolver which might be useful when you write your custom one. It takes the same arguments as your custom one, e.g. (request, options).

restoreMocks [boolean]

默认值︰false

Automatically restore mock state 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.

rootDir [string]

Default: The root of the directory containing your Jest config file or the package.json or the pwd if no package.json is found

The root directory that Jest should scan for tests and modules within. If you put your Jest config inside your package.json and want the root directory to be the root of your repo, the value for this config param will default to the directory of the package.json.

Oftentimes, you'll want to set this to 'src' or 'lib', corresponding to where in your repository the code is stored.

Note that using '<rootDir>' as a string token in any other path-based config settings will refer back to this value. So, for example, if you want your setupFiles config entry to point at the env-setup.js file at the root of your project, you could set its value to ["<rootDir>/env-setup.js"].

roots [array<string>]

默认值︰["<rootDir>"]

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

There are times where you only want Jest to search in a single sub-directory (such as cases where you have a src/ directory in your repo), but prevent it from accessing the rest of the repo.

Note: While rootDir is mostly used as a token to be re-used in other configuration options, roots is used by the internals of Jest to locate test files and source files. This applies also when searching for manual mocks for modules from node_modules (__mocks__ will need to live in one of the roots).

Note: By default, roots has a single entry <rootDir> but there are cases where you may want to have multiple roots within one project, for example roots: ["<rootDir>/src/", "<rootDir>/tests/"].

runner [string]

Default: "jest-runner"

This option allows you to use a custom runner instead of Jest's default test runner. Examples of runners include:

• jest-runner-eslint
• jest-runner-mocha
• jest-runner-tsc
• jest-runner-prettier

Note: The runner property value can omit the jest-runner- prefix of the package name.

To write a test-runner, export a class with which accepts globalConfig in the constructor, and has a runTests method with the signature:

async runTests(
  tests: Array<Test>,
  watcher: TestWatcher,
  onStart: OnTestStart,
  onResult: OnTestSuccess,
  onFailure: OnTestFailure,
  options: TestRunnerOptions,
): Promise<void>

If you need to restrict your test-runner to only run in serial rather then being executed in parallel your class should have the property isSerial to be set as true.

setupFiles [array]

默认值：[]

A list of paths to modules that run some code to configure or set up the testing environment. Each setupFile will be run once per test file. Since every test runs in its own environment, these scripts will be executed in the testing environment immediately before executing the test code itself.

It's also worth noting that setupFiles will execute before setupFilesAfterEnv.

setupFilesAfterEnv [array]

默认值：[]

A list of paths to modules that run some code to configure or set up the testing framework before each test. Since setupFiles executes before the test framework is installed in the environment, this script file presents you the opportunity of running some code immediately after the test framework has been installed in the environment.

If you want a path to be relative to the root directory of your project, please include <rootDir> inside a path's string, like "<rootDir>/a-configs-folder".

For example, Jest ships with several plug-ins to jasmine that work by monkey-patching the jasmine API. If you wanted to add even more jasmine plugins to the mix (or if you wanted some custom, project-wide matchers for example), you could do so in these modules.

Note: setupTestFrameworkScriptFile is deprecated in favor of setupFilesAfterEnv.

Example setupFilesAfterEnv array in a jest.config.js:

module.exports = {
  setupFilesAfterEnv: ['./jest.setup.js'],
};

Example jest.setup.js file

jest.setTimeout(10000); // in milliseconds

snapshotResolver [string]

默认值：undefined

The path to a module that can resolve test<->snapshot path. This config option lets you customize where Jest stores snapshot files on disk.

Example snapshot resolver module:

module.exports = {
  // resolves from test to snapshot path
  resolveSnapshotPath: (testPath, snapshotExtension) =>
    testPath.replace('__tests__', '__snapshots__') + snapshotExtension,

  // resolves from snapshot to test path
  resolveTestPath: (snapshotFilePath, snapshotExtension) =>
    snapshotFilePath
      .replace('__snapshots__', '__tests__')
      .slice(0, -snapshotExtension.length),

  // Example test path, used for preflight consistency check of the implementation above
  testPathForConsistencyCheck: 'some/__tests__/example.test.js',
};

snapshotSerializers [array<string>]

默认值：[]

A list of paths to snapshot serializer modules Jest should use for snapshot testing.

Jest has default serializers for built-in JavaScript types, HTML elements (Jest 20.0.0+), ImmutableJS (Jest 20.0.0+) and for React elements. See snapshot test tutorial for more information.

Example serializer module:

// my-serializer-module
module.exports = {
  print(val, serialize, indent) {
    return 'Pretty foo: ' + serialize(val.foo);
  },

  test(val) {
    return val && val.hasOwnProperty('foo');
  },
};

serialize is a function that serializes a value using existing plugins.

To use my-serializer-module as a serializer, configuration would be as follows:

{
  ...
  "jest": {
    "snapshotSerializers": ["my-serializer-module"]
  }
}

Finally tests would look as follows:

test(() => {
  const bar = {
    foo: {
      x: 1,
      y: 2,
    },
  };

  expect(bar).toMatchSnapshot();
});

Rendered snapshot:

Pretty foo: Object {
  "x": 1,
  "y": 2,
}

To make a dependency explicit instead of implicit, you can call expect.addSnapshotSerializer to add a module for an individual test file instead of adding its path to snapshotSerializers in Jest configuration.

testEnvironment [string]

默认值︰"jsdom"

The test environment that will be used for testing. The default environment in Jest is a browser-like environment through jsdom. If you are building a node service, you can use the node option to use a node-like environment instead.

By adding a @jest-environment docblock at the top of the file, you can specify another environment to be used for all tests in that file:

/**
 * @jest-environment jsdom
 */

test('use jsdom in this test file', () => {
  const element = document.createElement('div');
  expect(element).not.toBeNull();
});

You can create your own module that will be used for setting up the test environment. The module must export a class with setup, teardown and runScript methods. You can also pass variables from this module to your test suites by assigning them to this.global object – this will make them available in your test suites as global variables.

The class may optionally expose a handleTestEvent method to bind to events fired by jest-circus.

Any docblock pragmas in test files will be passed to the environment constructor and can be used for per-test configuration. If the pragma does not have a value, it will be present in the object with it's value set to an empty string. If the pragma is not present, it will not be present in the object.

Note: TestEnvironment is sandboxed. Each test suite will trigger setup/teardown in their own TestEnvironment.

示例：

// my-custom-environment
const NodeEnvironment = require('jest-environment-node');

class CustomEnvironment extends NodeEnvironment {
  constructor(config, context) {
    super(config, context);
    this.testPath = context.testPath;
    this.docblockPragmas = context.docblockPragmas;
  }

  async setup() {
    await super.setup();
    await someSetupTasks(this.testPath);
    this.global.someGlobalObject = createGlobalObject();

    // Will trigger if docblock contains @my-custom-pragma my-pragma-value
    if (this.docblockPragmas['my-custom-pragma'] === 'my-pragma-value') {
      // ...
    }
  }

  async teardown() {
    this.global.someGlobalObject = destroyGlobalObject();
    await someTeardownTasks();
    await super.teardown();
  }

  runScript(script) {
    return super.runScript(script);
  }

  handleTestEvent(event, state) {
    if (event.name === 'test_start') {
      // ...
    }
  }
}

module.exports = CustomEnvironment;

// my-test-suite
let someGlobalObject;

beforeAll(() => {
  someGlobalObject = global.someGlobalObject;
});

testEnvironmentOptions [Object]

默认值：{}

Test environment options that will be passed to the testEnvironment. The relevant options depend on the environment. For example you can override options given to jsdom such as {userAgent: "Agent/007"}.

testMatch [array<string>]

(default: [ "**/__tests__/**/*.[jt]s?(x)", "**/?(*.)+(spec|test).[jt]s?(x)" ])

The glob patterns Jest uses to detect test files. By default it looks for .js, .jsx, .ts and .tsx files inside of __tests__ folders, as well as any files with a suffix of .test or .spec (e.g. Component.test.js or Component.spec.js). It will also find files called test.js or spec.js.

See the micromatch package for details of the patterns you can specify.

See also testRegex [string | array<string>], but note that you cannot specify both options.

testPathIgnorePatterns [array<string>]

默认值︰["node_modules"]

An array of regexp pattern strings that are matched against all test paths before executing the test. If the test path matches any of the patterns, it will be skipped.

These pattern strings match against the full path. Use the <rootDir> string token to include the path to your project's root directory to prevent it from accidentally ignoring all of your files in different environments that may have different root directories. Example: ["<rootDir>/build/", "<rootDir>/node_modules/"].

testRegex [string | array<string>]

Default: (/__tests__/.*|(\\.|/)(test|spec))\\.[jt]sx?$

The pattern or patterns Jest uses to detect test files. By default it looks for .js, .jsx, .ts and .tsx files inside of __tests__ folders, as well as any files with a suffix of .test or .spec (e.g. Component.test.js or Component.spec.js). It will also find files called test.js or spec.js. See also testMatch [array<string>], but note that you cannot specify both options.

The following is a visualization of the default regex:

├── __tests__
│   └── component.spec.js # test
│   └── anything # test
├── package.json # not test
├── foo.test.js # test
├── bar.spec.jsx # test
└── component.js # not test

Note: testRegex will try to detect test files using the absolute file path therefore having a folder with name that match it will run all the files as tests

testResultsProcessor [string]

默认值：undefined

This option allows the use of a custom results processor. This processor must be a node module that exports a function expecting an object with the following structure as the first argument and return it:

{
  "success": bool,
  "startTime": epoch,
  "numTotalTestSuites": number,
  "numPassedTestSuites": number,
  "numFailedTestSuites": number,
  "numRuntimeErrorTestSuites": number,
  "numTotalTests": number,
  "numPassedTests": number,
  "numFailedTests": number,
  "numPendingTests": number,
  "numTodoTests": number,
  "openHandles": Array<Error>,
  "testResults": [{
    "numFailingTests": number,
    "numPassingTests": number,
    "numPendingTests": number,
    "testResults": [{
      "title": string (message in it block),
      "status": "failed" | "pending" | "passed",
      "ancestorTitles": [string (message in describe blocks)],
      "failureMessages": [string],
      "numPassingAsserts": number,
      "location": {
        "column": number,
        "line": number
      }
    },
    ...
    ],
    "perfStats": {
      "start": epoch,
      "end": epoch
    },
    "testFilePath": absolute path to test file,
    "coverage": {}
  },
  ...
  ]
}

testRunner [string]

默认值︰jasmine2

This option allows use of a custom test runner. The default is jasmine2. A custom test runner can be provided by specifying a path to a test runner implementation.

The test runner module must export a function with the following signature:

function testRunner(
  config: Config,
  environment: Environment,
  runtime: Runtime,
  testPath: string,
): Promise<TestResult>;

An example of such function can be found in our default jasmine2 test runner package.

testSequencer [string]

Default: @jest/test-sequencer

This option allows you to use a custom sequencer instead of Jest's default. sort may optionally return a Promise.

示例：

Sort test path alphabetically.

const Sequencer = require('@jest/test-sequencer').default;

class CustomSequencer extends Sequencer {
  sort(tests) {
    // Test structure information
    // https://github.com/facebook/jest/blob/6b8b1404a1d9254e7d5d90a8934087a9c9899dab/packages/jest-runner/src/types.ts#L17-L21
    const copyTests = Array.from(tests);
    return copyTests.sort((testA, testB) => (testA.path > testB.path ? 1 : -1));
  }
}

module.exports = CustomSequencer;

testURL [string]

Default: http://localhost

This option sets the URL for the jsdom environment. It is reflected in properties such as location.href.

timers [string]

默认值︰real

Setting this value to fake allows the use of fake timers for functions such as setTimeout. Fake timers are useful when a piece of code sets a long timeout that we don't want to wait for in a test.

transform [object<string, pathToTransformer | [pathToTransformer, object]>]

默认值：undefined

A map from regular expressions to paths to transformers. A transformer is a module that provides a synchronous function for transforming source files. For example, if you wanted to be able to use a new language feature in your modules or tests that isn't yet supported by node, you might plug in one of many compilers that compile a future version of JavaScript to a current one. Example: see the examples/typescript example or the webpack tutorial.

Examples of such compilers include:

• Babel
• TypeScript
• async-to-gen
• To build your own please visit the Custom Transformer section

You can pass configuration to a transformer like {filePattern: ['path-to-transformer', {options}]} For example, to configure babel-jest for non-default behavior, {"\\.js$": ['babel-jest', {rootMode: "upward"}]}

Note: a transformer is only run once per file unless the file has changed. During development of a transformer it can be useful to run Jest with --no-cache to frequently delete Jest's cache.

Note: if you are using the babel-jest transformer and want to use an additional code preprocessor, keep in mind that when "transform" is overwritten in any way the babel-jest is not loaded automatically anymore. If you want to use it to compile JavaScript code it has to be explicitly defined. See babel-jest plugin

transformIgnorePatterns [array<string>]

默认值︰["node_modules"]

An array of regexp pattern strings that are matched against all source file paths before transformation. If the test path matches any of the patterns, it will not be transformed.

These pattern strings match against the full path. Use the <rootDir> string token to include the path to your project's root directory to prevent it from accidentally ignoring all of your files in different environments that may have different root directories.

Example: ["<rootDir>/bower_components/", "<rootDir>/node_modules/"].

Sometimes it happens (especially in React Native or TypeScript projects) that 3rd party modules are published as untranspiled. Since all files inside node_modules are not transformed by default, Jest will not understand the code in these modules, resulting in syntax errors. To overcome this, you may use transformIgnorePatterns to whitelist such modules. You'll find a good example of this use case in React Native Guide.

unmockedModulePathPatterns [array<string>]

默认值：[]

An array of regexp pattern strings that are matched against all modules before the module loader will automatically return a mock for them. If a module's path matches any of the patterns in this list, it will not be automatically mocked by the module loader.

This is useful for some commonly used 'utility' modules that are almost always used as implementation details almost all the time (like underscore/lo-dash, etc). It's generally a best practice to keep this list as small as possible and always use explicit jest.mock()/jest.unmock() calls in individual tests. Explicit per-test setup is far easier for other readers of the test to reason about the environment the test will run in.

It is possible to override this setting in individual tests by explicitly calling jest.mock() at the top of the test file.

verbose [boolean]

默认值︰false

Indicates whether each individual test should be reported during the run. All errors will also still be shown on the bottom after execution.

watchPathIgnorePatterns [array<string>]

默认值：[]

An array of RegExp patterns that are matched against all source file paths before re-running tests in watch mode. If the file path matches any of the patterns, when it is updated, it will not trigger a re-run of tests.

These patterns match against the full path. Use the <rootDir> string token to include the path to your project's root directory to prevent it from accidentally ignoring all of your files in different environments that may have different root directories. Example: ["<rootDir>/node_modules/"].

watchPlugins [array<string | [string, Object]>]

默认值：[]

This option allows you to use a custom watch plugins. Read more about watch plugins here.

Examples of watch plugins include:

• jest-watch-master
• jest-watch-select-projects
• jest-watch-suspend
• jest-watch-typeahead
• jest-watch-yarn-workspaces

Note: The values in the watchPlugins property value can omit the jest-watch- prefix of the package name.

// [string]

No default

This option allow comments in package.json. Include the comment text as the value of this key anywhere in package.json.

示例：

{
  "name": "my-project",
  "jest": {
    "//": "Comment goes here",
    "verbose": true
  }
}