Configuring Jest

Configuração do Jest pode ser definida no arquivo package.json do seu projeto, através de um arquivo jest.config.js ou através da opção --config <path/to/js|json>. Se você optar pelo package.json para armazenar a configuração do Jest, a propriedade "jest" deve ser definida na raiz para que então o Jest consiga localiza-la:

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

Quando usando a opção --config, o arquivo JSON não deve conter a propriedade "jest":

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

Opções #

Estas opções permitem você controlar o comportamento do Jest em seu package.json. A filosofia do Jest é funcionar bem por padrão, mas às vezes você precisa de mais poder de configuração.

Referência #

`automock` [boolean] #

Padrão: false

Esta opção é desabilitada por padrão. Se você está introduzindo o Jest para uma grande empresa com um código existente mas com poucos testes, habilitar esta opção pode ser útil para adicionar testes unitários gradualmente. Módulos podem ser explicitamente auto-simulados usando jest.mock(moduleName).

Observação: módulos core, como o fs, não são simulados (mocked, em inglês) por padrão. Eles podem ser simulados explicitamente, como em jest.mock('fs').

Observação: Simulações automáticas (automocking, em inglês) possuem um custo de performance perceptível em projetos grandes. Veja aqui para mais detalhes e como contornar a situação.

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

`bail` [boolean] #

Padrão: false

Por padrão, o Jest executa todos os testes e exibe todos os erros no console após sua conclusão. A opção "bail" pode ser usada aqui para fazer o Jest parar de rodar os testes depois da primeira falha.

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

`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

Um array de padrões glob indicando certos arquivos que devem ser coletados informações de cobertura. Se um arquivo corresponde com o padrão glob especificado, a informação de cobertura será coletada para ele mesmo que não hajam testes existentes para este arquivo e se este nunca foi requisitado na suite de testes.

Exemplo:

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

Isto irá coletar informação de cobertura para todos os arquivos dentro da pasta rootDir dentro do projeto, exceto os que baterem com **/node_modules/** ou **/vendor/**.

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

`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/"]

Um array com um padrão regex que corresponda com todos os diretórios antes de executar os testes. Se o diretório corresponder qualquer uma das regex, as informações da coleta serão ignoradas.

Estes padrões de string devem corresponder com o diretório completo. Use o token string <rootDir> para incluir o caminho para o diretório raiz de seu projeto, para evitar que todos os seus arquivos sejam acidentalmente ignorados em diferentes ambientes que possam ter diretórios raíz diferentes. Exemplo: ["<rootDir>/build/", "<rootDir>/node_modules/"].

`coverageReporters` [array<string>] #

Padrão: ["json", "lcov", "text"]

Uma lista de nomes de reportadores que o Jest usa ao escrever relatórios de cobertura. Qualquer Reportador istanbul pode ser usado.

Nota: Esta opção sobrescreve os valores padrão. Adicione "text" ou "text-summary" para ver um resumo da cobertura na saída do console.

`coverageThreshold` [object] #

Padrão: undefined

Isto será usado para configurar a imposição de limite mínimo para os resultados de cobertura. Se os limites não forem atendidos, Jest retornará uma falha. Limites, quando especificados como números positivos, são tomados como o percentual mínimo exigido. Quando um limite é especificado como um número negativo, ele representa o número máximo de entidades não cobertas permitido.

Por exemplo, statements: 90 significa que a cobertura mínima é de 90%. statements: -10 significa que não mais que 10 declarações não cobertas são permitidas.

{
  ...
  "jest": {
    "coverageThreshold": {
      "global": {
        "branches": 50,
        "functions": 50,
        "lines": 50,
        "statements": 50
      }
    }
  }
}

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

`mapCoverage` [boolean] #

disponível no Jest 20.0.0+ #

Padrão: false

Se você tiver transformadores configurados que emitam mapas de origem (source maps, em inglês), Jest irá usá-los para tentar mapear a cobertura comparada ao código fonte original quando estiver escrevendo relatórios e checando limites. Isto é feito em uma base de melhor esforço, visto que algumas linguagens que compilam para Javascript podem fornecer mapas de origem mais precisos que outras. Isto também pode fazer uso intensivo de recursos. Se o Jest está tomando muito tempo para calcular a cobertura ao final da execução de um teste, tente alterar esta opção para false.

Tanto mapas de origem (source maps, em inglês) inline quanto mapas de origem retornados diretamente de um transformador são suportados. URLs de mapas de origem não são suportados pois o Jest pode não ser capaz de localizá-los. Para retornar mapas de origem de um transformador, a função process pode retornar um objeto conforme a seguir. A propriedade map pode tanto ser o objeto do mapa de origem, ou o objeto do mapa de origem como uma string JSON.

return {
  code: 'o código',
  map: 'o mapa de origem',
};

`moduleFileExtensions` [array<string>] #

Padrão: ["js", "json", "jsx", "node"...]

Um array de extensões de arquivos que seus módulos usam. Se você requerer módulos sem especificar uma extensão de arquivo, estas serão as extensões que o Jest irá procurar.

Se você está usando Typescript, esta opção deve ser ["js", "jsx", "json", "ts", "tsx"]

`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. Esta opção irá sobrepor o padrão, se você ainda deseja pesquisar node_modules por pacotes, inclua juntamente com outras opções: ["node_modules", "bower_components"]

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

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.

`modulePaths` [array<string>] #

Padrão: []

Uma API alternativa para definir a variável env NODE_PATH, modulePaths é um array de caminhos absolutos para locais adicionais para pesquisar ao resolver módulos. 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.

`preset` [string] #

Padrão: undefined

Uma predefinição que é usada como base para a configuração do Jest. Uma predefinição deve apontar para um módulo npm que exporta um módulo jest-preset.json em seu nível mais alto.

`projects` [array<string>] #

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>/exemplos/*"
  ]
}

Este exemplo de configuração irá executar Jest no diretório raiz, bem como em todas as pastas nos diretórios do exemplo. Você pode ter uma quantidade ilimitada de projetos em execução na mesma instância Jest.

`clearMocks` [boolean] #

Padrão: false

Limpe automaticamente chamadas simuladas (mock calls, em inglês) e instâncias entre cada teste. Equivalente à chamada jest.clearAllMocks() entre cada teste. Isso não remove qualquer implementação de simulação (mock, em inglês) que pode ter sido fornecida.

`reporters` [array<modulename | [modulename, options]>] #

Padrão: undefined

disponível no Jest 20.0.0+ #

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.

Se os reportadores personalizados forem especificados, os reportadores padrão do Jest serão substituídos. Para manter os reportadores padrão, default pode ser passado como um nome de módulo.

Isto irá sobrepor os reportadores padrão:

{
  "reporters": [
    "<rootDir>/meu-reportador-customizado.js"
  ]
}

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

{
  "reporters": [
    "default",
    "<rootDir>/meu-reportador-customizado.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('meu-reportador-customizado.js reportou um erro');
    }
  }
}

Para a lista completa dos métodos e tipos de argumento, consulte o tipo reporter em types/TestRunner.js

`resetMocks` [boolean] #

Padrão: false

Automaticamente redefina o estado simulado (mock, em inglês) entre cada teste. Equivalente à chamada jest.resetAllMocks() entre cada teste. 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

Se habilitado, o registro do módulo para cada arquivo de teste será redefinido antes de executar cada teste individual. Isso é útil para isolar módulos para cada teste, para que o estado do módulo local não entre em conflito entre os testes. Isso pode ser feito por meio de programação usando jest.resetModules().

`resolver` [string] #

Padrão: undefined

disponível no Jest 20.0.0+ #

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": bool,
  "extensions": [string],
  "moduleDirectory": [string],
  "paths": [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.

`rootDir` [string] #

Padrão: A raiz do diretório que contém o package.json ou o pwd se nenhum package.json for encontrado

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. Por padrão, roots tem uma única entrada <rootDir> mas existem casos onde você deseja ter múltiplas raízes dentro de um projeto, por exemplo roots: ["<rootDir>/src/", "<rootDir>/tests/"].

`setupFiles` [array] #

Padrão: []

Os caminhos para módulos que executam algum código para configurar o ambiente de teste antes de cada teste. 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.

É interessante notar que este código será executado antes de setupTestFrameworkScriptFile.

`setupTestFrameworkScriptFile` [string] #

Padrão: undefined

O caminho para um módulo que execute algum código para configurar o framework de teste antes de cada teste. 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.

Por exemplo, Jest vem com vários plugins para jasmine que trabalham por "mokey-patching" a API do jasmine. Se você quisesse adicionar ainda mais plugins jasmine à mistura (ou se você queria combinar alguns personalizados, por exemplo "matchers" para todo o projeto), você pode fazê-lo neste módulo.

`snapshotSerializers` [array<string>] #

Padrão: []

Uma lista de caminhos para módulos de serializador de snapshot que Jest deve usar para teste de snapshot.

Jest tem serializadores padrão para tipos internos de JavaScript, elementos HTML (Jest 20.0.0+), ImmutableJS (Jest 20.0.0+) e para elementos React. Veja tutorial de teste snapshot para obter mais informações.

Exemplo de módulo serializador:

// meu-modulo-serializador
module.exports = {
  print(val, serialize, indent) {
    return 'foo arrumado: ' + serialize(val.foo);
  },

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

};

serialize é uma função que serializa um valor usando plugins existentes.

Para usar o my-serializer-module como um serializador, a configuração seria como segue:

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

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

Se alguns testes exigem um outro ambiente, você pode adicionar um "docblock" @jest-environment.

disponível no Jest 20.0.0+ #

/**
 * @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. O módulo deve exportar uma classe com métodos runScript e dispose. Consulte os ambientes node ou jsdom como exemplos.

`testMatch` [array<string>] #

disponível no Jest 19.0.0+ #

(padrão: [ '**/__tests__/**/*.js?(x)', '**/?(*.)(spec|test).js?(x)' ])

Os padrões glob que Jest usa para detectar arquivos de teste. Por padrão, ele procura por arquivos .js e .jsx dentro de pastas __tests__, bem como todos os arquivos com um sufixo de .test ou .spec (por exemplo, Component.test.js ou Component.spec.js). Ele também irá encontrar arquivos chamados test.js ou spec.js.

Veja o pacote micromatch para obter detalhes sobre os padrões que você pode especificar.

Veja também testRegex [string], mas note que não é possível especificar ambas as opções.

`testPathIgnorePatterns` [array<string>] #

Padrão: ["/node_modules/"]

Uma array de padrões strings de regexp que são comparadas contra todos os caminhos de teste antes de executar o teste. Se o caminho de teste coincide com qualquer um dos padrões, ele será ignorado.

`testRegex` [string] #

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

O padrão que Jest usa para detectar arquivos de teste. Por padrão, ele procura por arquivos .js e .jsx dentro de pastas __tests__, bem como todos os arquivos com um sufixo de .test ou .spec (por exemplo, Component.test.js ou Component.spec.js). Ele também irá encontrar arquivos chamados test.js ou spec.js. Veja também testMatch [array<string>], mas note que não é possível especificar ambas as opções.

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

`testResultsProcessor` [string] #

Padrão: undefined

Esta opção permite o uso de um processador de resultados personalizado. Este processador deve ser um módulo node que exporta uma função esperando um objeto com a seguinte estrutura como o primeiro argumento:

{
  "success": bool,
  "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 (mensagem do bloco it),
      "status": "failed" | "pending" | "passed",
      "ancestorTitles": [string (mensagem do bloco describe)],
      "failureMessages": [string],
      "numPassingAsserts": number
    },
    ...
    ],
    "perfStats": {
      "start": epoch,
      "end": epoch
    },
    "testFilePath": caminho absoluto para o arquivo,
    "coverage": {}
  },
  ...
  ]
}

`testRunner` [string] #

Padrão: jasmine2

Esta opção permite a utilização de um executador de testes personalizado. O padrão é jasmine2. Um executador de testes personalizado pode ser fornecido, especificando um caminho para uma implementação do executador de teste.

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

function testRunner(
  config: Config,
  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

Esta opção define a URL para o ambiente jsdom. É refletida em propriedades tais como 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>] #

Padrão: undefined

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. Por exemplo, se você queria ser capaz de usar um novo recurso da linguagem em seus módulos ou testes que ainda não é suportado pelo node, você pode conectar em um dos muitos compiladores que compilam de uma versão futura do JavaScript para uma atual. Exemplo: veja o exemplo examples/typescript ou o tutorial webpack.

Exemplos de tais compiladores incluem babel, typescript e async-to-gen.

Nota: um transformador roda apenas uma vez por arquivo a menos que o arquivo foi alterado. Durante o desenvolvimento de um transformador pode ser útil executar Jest com --no-cache ou frequentemente excluir o cache do Jest.

Nota: se você estiver usando o transformador babel-jest e quer usar um pré-processador adicional de código, tenha em mente que quando "transform" é substituído de alguma forma, o babel-jest não é mais carregado automaticamente. Se você quiser usá-lo para compilar o código JavaScript ele tem que ser definido explicitamente. Veja babel-jest plugin

`transformIgnorePatterns` [array<string>] #

Padrão: ["/node_modules/"]

Uma array de string padrão de regexp são comparados contra todos os caminhos de arquivo de origem, antes da transformação. Se o caminho de teste coincide com qualquer um dos padrões, isso não será transformado.

`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

Indica se cada teste individual deve ser relatado durante a execução. Todos os erros irão também aparecer na parte inferior após a execução.

Opções #

Referência #

automock [boolean] #

browser [boolean] #

bail [boolean] #

cacheDirectory [string] #

collectCoverage [boolean] #

collectCoverageFrom [array] #

coverageDirectory [string] #

coveragePathIgnorePatterns [array<string>] #

coverageReporters [array<string>] #

coverageThreshold [object] #

globals [object] #

mapCoverage [boolean] #

disponível no Jest 20.0.0+ #

moduleFileExtensions [array<string>] #

moduleDirectories [array<string>] #

moduleNameMapper [object<string, string>] #

modulePathIgnorePatterns [array<string>] #

modulePaths [array<string>] #

notify [boolean] #

preset [string] #

projects [array<string>] #

clearMocks [boolean] #

reporters [array<modulename | [modulename, options]>] #

disponível no Jest 20.0.0+ #

resetMocks [boolean] #

resetModules [boolean] #

resolver [string] #

disponível no Jest 20.0.0+ #

rootDir [string] #

roots [array<string>] #

setupFiles [array] #

setupTestFrameworkScriptFile [string] #

snapshotSerializers [array<string>] #

testEnvironment [string] #

disponível no Jest 20.0.0+ #

testMatch [array<string>] #

disponível no Jest 19.0.0+ #

testPathIgnorePatterns [array<string>] #

testRegex [string] #

testResultsProcessor [string] #

testRunner [string] #

testURL [string] #

timers [string] #

transform [object<string, string>] #

transformIgnorePatterns [array<string>] #

unmockedModulePathPatterns [array<string>] #

verbose [boolean] #

`automock` [boolean] #

`browser` [boolean] #

`bail` [boolean] #

`cacheDirectory` [string] #

`collectCoverage` [boolean] #

`collectCoverageFrom` [array] #

`coverageDirectory` [string] #

`coveragePathIgnorePatterns` [array<string>] #

`coverageReporters` [array<string>] #

`coverageThreshold` [object] #

`globals` [object] #

`mapCoverage` [boolean] #

`moduleFileExtensions` [array<string>] #

`moduleDirectories` [array<string>] #

`moduleNameMapper` [object<string, string>] #

`modulePathIgnorePatterns` [array<string>] #

`modulePaths` [array<string>] #

`notify` [boolean] #

`preset` [string] #

`projects` [array<string>] #

`clearMocks` [boolean] #

`reporters` [array<modulename | [modulename, options]>] #

`resetMocks` [boolean] #

`resetModules` [boolean] #

`resolver` [string] #

`rootDir` [string] #

`roots` [array<string>] #

`setupFiles` [array] #

`setupTestFrameworkScriptFile` [string] #

`snapshotSerializers` [array<string>] #

`testEnvironment` [string] #

`testMatch` [array<string>] #

`testPathIgnorePatterns` [array<string>] #

`testRegex` [string] #

`testResultsProcessor` [string] #

`testRunner` [string] #

`testURL` [string] #

`timers` [string] #

`transform` [object<string, string>] #

`transformIgnorePatterns` [array<string>] #

`unmockedModulePathPatterns` [array<string>] #

`verbose` [boolean] #