22.x

Edit

Configuring Jest

A configuração do Jest pode ser definida no arquivo package.json do seu projeto, ou por meio de um arquivo jest.config.js, ou então pela opção do --config <path/to/file.js|json>. Se você deseja usar o seu arquivo package.json para armazenar a configuração do Jest, a chave "jest" deve ser adicionada no nível superior para que o Jest saiba como encontrar sua configuração:

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

Ou através de JavaScript:

// jest.config.js
module.exports = {
  verbose: true,
};

Por favor, tenha em mente que a configuração resultante deve ser JSON-serializável.

Ao usar a opção --config, o arquivo JSON não deve conter uma chave "jest":

{
  "bail": true,
  "verbose": true
}

Opções

These options let you control Jest's behavior in your package.json file. The Jest philosophy is to work great by default, but sometimes you just need more configuration power.

Referência

automock [boolean]

Padrão: false

This option tells Jest that all imported modules in your tests should be mocked automatically. All modules used in your tests will have a replacement implementation, keeping the API surface.

Exemplo:

// 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();
});

Note: Node modules are automatically mocked when you have a manual mock in place (e.g.: __mocks__/lodash.js). More info here.

Note: Core modules, like fs, are not mocked by default. They can be mocked explicitly, like jest.mock('fs').

bail [boolean]

Padrão: false

By default, Jest runs all tests and produces all errors into the console upon completion. The bail config option can be used here to have Jest stop running tests after the first failure.

browser [boolean]

Padrão: false

Respeite o campo "browser" do Browserify no package.json quando for resolver módulos. Alguns módulos exportam diferentes versões dependendo se estiverem operando no Node ou em algum navegador.

cacheDirectory [string]

Padrão: "/tmp/<path>"

O diretório onde o Jest deve armazenar as informações de suas dependências cacheadas.

O Jest tenta escanear sua árvore de dependências uma vez (antecipadamente) e a cacheia para facilitar algumas varreduras no filesystem que precisam acontecer enquanto seus testes estão rodando. Esta opção permite você personalizar aonde o Jest armazena aquela informação cacheada em disco.

clearMocks [boolean]

Padrão: false

Automatically clear mock calls and instances before every test. Equivalent to calling jest.clearAllMocks() before each test. Isso não remove qualquer implementação de simulação (mock, em inglês) que pode ter sido fornecida.

collectCoverage [boolean]

Padrão: false

Indica se a informação de cobertura deve ser coletada enquanto o teste é executado. Devido à isso adicionar a todos os arquivos executados declarações de coleta de cobertura, ele pode tornar os seus testes significantemente mais lentos.

collectCoverageFrom [array]

Padrão: undefined

An array of glob patterns indicating a set of files for which coverage information should be collected. If a file matches the specified glob pattern, coverage information will be collected for it even if no tests exist for this file and it's never required in the test suite.

Exemplo:

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

This will collect coverage information for all the files inside the project's rootDir, except the ones that match **/node_modules/** or **/vendor/**.

Observação: Esta opção requer que collectCoverage seja verdadeiro ou o Jest deverá ser invocado com --coverage.

Help: If you are seeing coverage output such as...

=============================== Coverage summary ===============================
Statements   : Unknown% ( 0/0 )
Branches     : Unknown% ( 0/0 )
Functions    : Unknown% ( 0/0 )
Lines        : Unknown% ( 0/0 )
================================================================================
Jest: Coverage data for global was not found.

Most likely your glob patterns are not matching any files. Refer to the micromatch documentation to ensure your globs are compatible.

coverageDirectory [string]

Padrão: undefined

O diretório onde o Jest deve salvar os seus arquivos de cobertura.

coveragePathIgnorePatterns [array<string>]

Padrão: ["/node_modules/"]

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

Estes padrões de string devem corresponder com o diretório completo. Use a opção <rootDir> para incluir o caminho para o diretório raiz do seu projeto, para evitar que ele ignore acidentalmente todos os seus arquivos em diferentes ambientes que podem ter diretórios raiz diferentes. Exemplo: ["<rootDir>/build/", "<rootDir>/node_modules/"].

coverageReporters [array<string>]

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

A list of reporter names that Jest uses when writing coverage reports. Any istanbul reporter can be used.

Note: Setting this option overwrites the default values. Add "text" or "text-summary" to see a coverage summary in the console output.

coverageThreshold [object]

Padrão: undefined

Isto será usado para configurar a imposição de limite mínimo para os resultados de cobertura. Thresholds can be specified as global, as a glob, and as a directory or file path. If thresholds aren't met, jest will fail. Thresholds specified as a positive number are taken to be the minimum percentage required. Thresholds specified as a negative number represent the maximum number of uncovered entities allowed.

For example, with the following configuration jest will fail if there is less than 80% branch, line, and function coverage, or if there are more than 10 uncovered statements:

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

If globs or paths are specified alongside global, coverage data for matching paths will be subtracted from overall coverage and thresholds will be applied independently. Thresholds for globs are applied to all files matching the glob. If the file specified by path is not found, an error is returned.

For example, with the following configuration:

{
  ...
  "jest": {
    "coverageThreshold": {
      "global": {
        "branches": 50,
        "functions": 50,
        "lines": 50,
        "statements": 50
      },
      "./src/components/": {
        "branches": 40,
        "statements": 40
      },
      "./src/reducers/**/*.js": {
        "statements": 90
      },
      "./src/api/very-important-module.js": {
        "branches": 100,
        "functions": 100,
        "lines": 100,
        "statements": 100
      }
    }
  }
}

Jest will fail if:

  • The ./src/components directory has less than 40% branch or statement coverage.
  • One of the files matching the ./src/reducers/**/*.js glob has less than 90% statement coverage.
  • The ./src/api/very-important-module.js file has less than 100% coverage.
  • Every remaining file combined has less than 50% coverage (global).

displayName [string]

padrão: undefined

Allows for a label to be printed alongside a test while it is running. This becomes more useful in multi-project repositories where there can be many jest configuration files. This visually tells which project a test belongs to.

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);
  });
}

You can collect coverage from those files with setting forceCoverageMatch.

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

globals [object]

Padrão: {}

Um conjunto de variáveis globais que precisam estar disponíveis em todos os ambientes de teste.

Por exemplo, a configuração a seguir criaria uma variável global __DEV__ definida como true em todos os ambientes de teste:

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

Note que, se você especificar um valor de referência global (como um objeto ou array) aqui, e algum código modificar este valor durante a execução de um teste, a modificação não será mantida ao longo da execução de testes para outros arquivos de teste. In addition, the globals object must be json-serializable, so it can't be used to specify global functions. For that, you should use setupFiles.

globalSetup [string]

Padrão: 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.

globalTeardown [string]

Padrão: 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.

haste [object]

Padrão: undefined

This will be used to configure the behavior of jest-haste-map, Jest's internal file crawler/cache system. The following options are supported:

type HasteConfig = {
  // Whether to hash files using SHA-1.
  computeSha1?: boolean;
  // The platform to use as the default, e.g. 'ios'.
  defaultPlatform?: string | null;
  // Path to a custom implementation of Haste.
  hasteImplModulePath?: string;
  // All platforms to target, e.g ['ios', 'android'].
  platforms?: Array<string>;
  // Whether to throw on error on module collision.
  throwOnModuleCollision?: boolean;
};

moduleDirectories [array<string>]

Padrão: ["/node_modules/"]

Uma array de nomes de diretórios a serem pesquisados recursivamente a partir da localização do módulo requerente. 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>]

Padrão: ["js", "json", "jsx", "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.

If you are using TypeScript, you will want to add "ts" and/or "tsx" to the above default. Where you place these is up to you - we recommend placing the extensions most commonly used in your project on the left.

moduleNameMapper [object<string, string>]

Padrão: null

Um mapa de expressões regulares para nomes de módulos que permitem esboçar recursos, como imagens ou estilos com um único módulo.

Módulos que são mapeados para um alias são não simuláveis por padrão, independentemente se auto simulação (automocking, em inglês) está habilitado ou não.

Use o token string <rootDir> para se referir ao valor rootDir se você quiser usar caminhos de arquivo.

Além disso, você pode substituir os grupos regex capturados usando referências anteriores numeradas.

Exemplo:

{
  "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.

Nota: Se você fornecer o nome do módulo sem limites ^$ pode causar erros difíceis de detectar. Por exemplo, o relay irá substituir todos os módulos que contêm o relay como uma subsequência de caracteres em seu nome: relay, react-relay e graphql-relay vão todos serem apontados para seu esboço.

modulePathIgnorePatterns [array<string>]

Padrão: []

Uma array de sequências de padrões regexp que são comparados contra todos os caminhos de módulo, antes desses caminhos serem considerados 'visíveis' para o carregador de módulos. Se o caminho de um determinado módulo coincide com qualquer um dos padrões, não será capaz de dar require() no ambiente de teste.

Estes padrões de string devem corresponder com o diretório completo. Use a opção <rootDir> para incluir o caminho para o diretório raiz do seu projeto, para evitar que ele ignore acidentalmente todos os seus arquivos em diferentes ambientes que podem ter diretórios raiz diferentes. Exemplo: ["<rootDir>/build/"].

modulePaths [array<string>]

Padrão: []

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 o token string <rootDir> para incluir o caminho para o diretório raiz do seu projeto. Exemplo: ["<rootDir>/app/"].

notify [boolean]

Padrão: false

Ativa notificações para os resultados do teste.

Beware: Jest uses node-notifier to display desktop notifications. On Windows, it creates a new start menu entry on the first use and not display the notification. Notifications will be properly displayed on subsequent runs

notifyMode [string]

Default: always

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]

Padrão: 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 to filesystem paths.

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

projects [array<string | projectconfig>]

Padrão: undefined

Quando a configuração projects é fornecida com um array de caminhos ou padrões glob, Jest executará testes em todos os projetos especificados ao mesmo tempo. Isso é ótimo para monorepos ou quando trabalhando em vários projetos ao mesmo tempo.

{
  "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]>]

Padrão: undefined

Use essa opção de configuração para adicionar reportadores personalizados ao Jest. Um reportador personalizado é uma classe que implementa métodos onRunStart, onTestStart, onTestResult, onRunComplete que serão chamados quando qualquer um desses eventos ocorrer.

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

Isto irá sobrepor os reportadores padrão:

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

Isto irá usar reportador personalizado além dos reportadores padrão que o Jest fornece:

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

Além disso, os reportadores personalizados podem ser configurados passando um objeto de options como um segundo argumento:

{
  "reporters": [
    "default",
    ["<rootDir>/meu-reportador-customizado.js", {"banana": "yes", "pineapple": "no"}]
  ]
}

Módulos reportador personalizados devem definir uma classe que leva um GlobalConfig e opções de reportador como argumentos do construtor:

Exemplo de reportador:

// meu-reportador-customizado.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;

Os reportadores personalizados também podem forçar Jest para sair com código "non-0", retornando um erro de métodos getLastError()

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]

Padrão: false

Automatically reset mock state before every test. Equivalent to calling jest.resetAllMocks() before each test. Isto levará a quaisquer simulações terem suas implementações falsas removidas mas não restaura sua implementação inicial.

resetModules [boolean]

Padrão: 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 the local module state doesn't conflict between tests. Isso pode ser feito por meio de programação usando jest.resetModules().

resolver [string]

Padrão: undefined

Esta opção permite o uso de um resolvedor personalizado. Esse resolvedor deve ser um módulo Node que exporta uma função esperando uma string como o primeiro argumento para resolver o caminho e um objeto com a seguinte estrutura como o segundo argumento:

{
  "basedir": string,
  "browser": boolean,
  "extensions": [string],
  "moduleDirectory": [string],
  "paths": [string],
  "rootDir": [string]
}

A função deve ou retornar um caminho para o módulo que deve ser resolvido ou lançar um erro se o módulo não pode ser encontrado.

restoreMocks [boolean]

Padrão: 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

O diretório raiz que Jest deve escanear para testes e módulos dentro. Se você colocar sua configuração do Jest dentro de seu package.json e quer que o diretório raiz seja a raiz de seu repositório, o valor padrão para este parâmetro de configuração será o diretório do package.json.

Muitas vezes, você vai querer definir este para 'src' ou 'lib', correspondente a onde em seu repositório o código é armazenado.

Observe que usando '<rootDir>' com um token string em qualquer outra configuração baseados em caminho irá se referir de volta a esse valor. Então, por exemplo, se você quer que sua configuração de entrada setupFiles aponte para o arquivo env-setup.js na raiz do seu projeto, você poderia definir seu valor como ["<rootDir>/env-setup.js"].

roots [array<string>]

Padrão: ["<rootDir>"]

Uma lista de caminhos para diretórios que Jest deve usar para pesquisar por arquivos.

Há momentos onde você quer que Jest procure apenas em um único sub-diretório (como os casos onde você tem um diretório src/ em seu repositório), mas impedi-lo de acessar o resto do repositório.

Nota: Enquanto rootDir é principalmente usado como um token para ser reutilizado em outras opções de configuração, roots é usado internamente por Jest para localizar arquivos de teste e arquivos fonte. This applies also when searching for manual mocks for modules from node_modules (__mocks__ will need to live in one of the roots).

Nota: Por padrão roots tem uma única entrada <rootDir> mas há casos onde você pode querer ter mútiplos roots dentro de um projeto, por exemplo 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:

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 than being executed in parallel your class should have the property isSerial to be set as true.

setupFiles [array]

Padrão: []

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. Como cada teste é executado em seu próprio ambiente, esses scripts serão executados no ambiente de teste imediatamente antes de executarem o código de teste em si.

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

setupTestFrameworkScriptFile [string]

Padrão: undefined

The path to a module that runs some code to configure or set up the testing framework before each test file in the suite is executed. Como o setupFiles é executado antes que o framework de teste é instalado no ambiente, este arquivo de script apresenta-lhe a oportunidade de executar algum código imediatamente depois que o framework de teste tiver sido instalado no ambiente.

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".

Por exemplo, Jest vem com vários plugins para jasmine que trabalham por "mokey-patching" a API do jasmine. 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.

Example setupTestFrameworkScriptFile in a jest.config.js:

module.exports = {
  setupTestFrameworkScriptFile: './jest.setup.js',
};

Example jest.setup.js file

jest.setTimeout(10000); // in milliseconds

snapshotSerializers [array<string>]

Padrão: []

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.

Exemplo de módulo serializador:

// my-serializer-module
module.exports = {
  serialize(val, config, indentation, depth, refs, printer) {
    return 'Pretty foo: ' + printer(val.foo);
  },

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

printer 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": ["meu-modulo-serializador"]
  }
}

Finalmente, os testes seriam os seguintes:

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

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

Snapshot renderizado:

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

Para tornar uma dependência explícita ao invés de implícita, você pode chamar expect.addSnapshotSerializer para adicionar um módulo para um arquivo de teste individual em vez de adicionar o seu caminho para snapshotSerializers na configuração do Jest.

More about serializers API can be found here.

testEnvironment [string]

Padrão: "jsdom"

O ambiente de teste que será usado para testes. O ambiente padrão em Jest é um ambiente semelhante com um navegador através de jsdom. Se você estiver criando um serviço node, você pode usar a opção node para usar um ambiente semelhante ao node em vez disso.

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();
});

Você pode criar seu próprio módulo que será usado para configurar o ambiente de teste. 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.

To use this class as your custom environment, refer to it by its full path within the project. For example, if your class is stored in my-custom-environment.js in some subfolder of your project, then the annotation might looke like this:

/**
 * @jest-environment ./src/test/my-custom-environment
 */

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

Exemplo:

// 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);
  }
}

module.exports = CustomEnvironment;

// my-test-suite
/**
 * @jest-environment ./my-custom-environment
 */
let someGlobalObject;

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

Note: Jest comes with JSDOM@11 by default. Due to JSDOM 12 and newer dropping support for Node 6, Jest is unable to upgrade for the time being. However, you can install a custom testEnvironment with whichever version of JSDOM you want. E.g. jest-environment-jsdom-thirteen, which has JSDOM@13.

testEnvironmentOptions [Object]

Padrão: {}

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"}.

testFailureExitCode [number]

Default: 1

The exit code Jest returns on test failure.

Note: This does not change the exit code in the case of Jest errors (e.g. invalid configuration).

testMatch [array<string>]

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

Os padrões glob que Jest usa para detectar arquivos de teste. By default it looks for .js and .jsx 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], but note that you cannot specify both options.

testPathIgnorePatterns [array<string>]

Padrão: ["/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.

Estes padrões de string devem corresponder com o diretório completo. Use a opção <rootDir> para incluir o caminho para o diretório raiz do seu projeto, para evitar que ele ignore acidentalmente todos os seus arquivos em diferentes ambientes que podem ter diretórios raiz diferentes. Exemplo: ["<rootDir>/build/", "<rootDir>/node_modules/"].

testRegex [string]

Padrão: (/__tests__/.*|(\\.|/)(test|spec))\\.jsx?$

O padrão que Jest usa para detectar arquivos de teste. By default it looks for .js and .jsx 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.

O seguinte é uma visualização do padrão 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 a name that matches it will run all the files as tests

testResultsProcessor [string]

Padrão: 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": boolean,
  "startTime": epoch,
  "numTotalTestSuites": number,
  "numPassedTestSuites": number,
  "numFailedTestSuites": number,
  "numRuntimeErrorTestSuites": number,
  "numTotalTests": number,
  "numPassedTests": number,
  "numFailedTests": number,
  "numPendingTests": number,
  "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": caminho absoluto para o arquivo,
    "coverage": {}
  },
  ...
  ]
}

testRunner [string]

Padrão: jasmine2

This option allows the 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.

O módulo executador de teste deve exportar uma função com a seguinte assinatura:

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

Um exemplo de tal função pode ser encontrado em nosso padrão jasmine2 test runner package.

testURL [string]

Padrão: about:blank

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

timers [string]

Padrão: real

Definir esse valor como fake permite o uso de temporizadores falsos para funções como setTimeout. Temporizadores falsos são úteis quando um pedaço de código define um "timeout" longo que não queremos esperar em um teste.

transform [object<string, string>]

Default: {"^.+\\.[jt]sx?$": "babel-jest"}

Um mapa de expressões regulares para caminhos para transformadores. Um transformador é um módulo que fornece uma função síncrona para transformar os arquivos de origem. 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 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:

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

Note: when adding additional code transformers, this will overwrite the default config and babel-jest is no longer automatically loaded. If you want to use it to compile JavaScript or Typescript, it has to be explicitly defined by adding {"\\.[jt]sx?$": "babel-jest"} to the transform property. Veja babel-jest plugin

transformIgnorePatterns [array<string>]

Padrão: ["/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.

Estes padrões de string devem corresponder com o diretório completo. Use a opção <rootDir> para incluir o caminho para o diretório raiz do seu projeto, para evitar que ele ignore acidentalmente todos os seus arquivos em diferentes ambientes que podem ter diretórios raiz diferentes.

Exemplo: ["<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 allow transpiling such modules. You'll find a good example of this use case in React Native Guide.

unmockedModulePathPatterns [array<string>]

Padrão: []

Uma array de strings padrão de regexp que são comparados com todos os módulos antes do carregador de módulo automaticamente retornar uma simulação (mock, em inglês) para eles. Se o caminho de um módulo coincide com qualquer um dos padrões nesta lista, ele não será automaticamente simulado (mocked, em inglês) pelo carregador de módulo.

Isso é útil para alguns módulos 'utility' comumente usados, que quase sempre são usados como detalhes de implementação (como underscore/lo-dash, etc). Geralmente é uma prática recomendada manter essa lista tão pequena quanto possível e sempre usar explicitamente chamadas jest.mock()/jest.unmock() nos testes individuais. Instalação explícita por teste é muito mais fácil para outros leitores do teste raciocinarem sobre o ambiente em que o teste será executado.

É possível substituir essa configuração nos testes individuais chamando explicitamente jest.mock() na parte superior do arquivo de teste.

verbose [boolean]

Padrão: false

Indicates whether each individual test should be reported during the run. All errors will also still be shown on the bottom after execution. Note that if there is only one test file being run it will default to true.

watchPathIgnorePatterns [array<string>]

Padrão: []

Uma série de padrões de RegExp que são compatíveis com todos os caminhos de arquivos de origem antes de executar novamente os testes no modo de observação. Se o caminho do arquivo corresponder a qualquer um dos padrões, quando ele for atualizado, ele não irá realizar uma nova execução de testes.

Esses padrões coincidem com um caminho completo. Use a opção <rootDir> para incluir o caminho para o diretório raiz do seu projeto, para evitar que ele ignore acidentalmente todos os seus arquivos em diferentes ambientes que podem ter diretórios raiz diferentes. Exemplo: ["<rootDir>/node_modules/"].

Even if nothing is specified here, the watcher will ignore changes to any hidden files and directories, i.e. files and folders that begin with a dot (.).

watchman [boolean]

Default: true

Whether to use watchman for file crawling.

← The Jest ObjectJest CLI Options →