Configuring Jest

Jest's configuration can be defined in the package.json file of your project, through a jest.config.js file or through the --config <path/to/js|json> option. Si se usa package.json para guardar la configuración de Jest, se debe usar la clave "jest" a nivel superior para que Jest sea capaz de encontrar las preferencias:

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

O a través de JavaScript:

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

Es importante notar que la configuración debe poder serializarse a un objeto JSON.

En cambio, cuando se utiliza la opción --config, el archivo JSON de configuración definido NO debe contener la clave "jest":

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

Opciones #

Estas opciones permiten controlar el comportamiento de Jest desde el archivo package.json. La filosofía de Jest es que funcione de manera excelente en automático; pero sabemos que a veces se necesita tener más control sobre la configuración.

Referencia #

`automock` [boolean] #

Por defecto: false

Esta opción esta inhabilitada por defecto. Activar esta opción puede ayudar a introducir pruebas unitarias de manera gradual cuando se comience a trabajar con Jest en proyectos existentes de gran tamaño y pocas pruebas. Cada modulo a ser simulado automáticamente (auto-mocked) puede ser definido de manera individual usando jest.mock(nombreDelModulo).

Nota: Los módulos centrales (core) como fs NO son simulados (mocked) de manera automática. Pero pueden ser simulados de manera explicita. En este caso con jest.mock('fs').

Nota: La simulación automática (automocking) tiene un efecto en el desempeño de las aplicaciones, el cual es más notable en grandes aplicaciones. Detalles y posibles soluciones pueden ser encontrados aquí.

`browser` [boolean] #

Por defecto: false

Esta opción respeta la opción "browser" de Browserify en package.json al momento de resolver módulos. Algunos módulos exportan diferentes versiones dependiendo de si son ejecutados sobre Node o un navegador.

`bail` [boolean] #

Por defecto: false

Por defecto Jest ejecuta todas las pruebas y, una vez terminadas, muestra todos los errores encontrados en la consola. La opción bail puede usarse para indicar a Jest que terminé la ejecución de pruebas al encontrar el primer error.

`cacheDirectory` [string] #

Por defecto: "/tmp/<path>"

Indica el directorio donde Jest debe guardar el caché de la información de las dependencias del proyecto.

Al iniciar, Jest intenta escanear el árbol de dependencias una vez y guardar la información en caché; con el objetivo de minimizar el trabajo que ocurre al trabajar con el sistema de archivos cuando las pruebas son ejecutadas. Esta opción permite configurar donde es que Jest guarda este caché en disco.

`collectCoverage` [boolean] #

Por defecto: false

Indica si la información de cobertura debe ser recolectada al momento de ejecutar las pruebas. Activar esta opción puede alentar de manera significativa el tiempo de ejecución de las pruebas; pues se agregan sentencias temporales, para la recolección de cobertura, en todos los archivos ejecutados.

`collectCoverageFrom` [array] #

Por defecto: undefined

Arreglo de patrones que definen el conjunto de archivos para los cuales se debe recolectar información de cobertura. La información de cobertura es recolectada para todos los archivos que cumplan el patrón; sin importar si existen pruebas que ocupen dichos archivos.

Ejemplo:

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

El patrón anterior hará que Jest recolecte información de cobertura de todos los archivos dentro del directorio raíz rootDir del proyecto, con excepción de aquellos que entren en el patrón de **/node_modules/** o **/vendor/**.

Nota: Esta opción requiere que collectCoverage se defina como true o que Jest sea ejecutado con la opción --coverage.

`coverageDirectory` [string] #

Por defecto: undefined

El directorio donde Jest escribe los archivos de resultados del análisis de cobertura.

`coveragePathIgnorePatterns` [array<string>] #

Por defecto: ["/node_modules/"]

Arreglo de patrones de expresiones regulares regexp con el que se comparan todos los directorios del proyecto antes de la ejecución de pruebas. Cualquier archivo que entre en la expresión será omitido durante el análisis de cobertura.

Estos patrones se comparan contra la ruta completa. Use la cadena <rootDir> para incluir la ruta del proyecto. Esto garantiza que el proyecto no sea omitido por accidente en ambientes distintos que puedan tener diferentes directorios raíz. Ejemplo: ["<rootDir>/build/", "<rootDir>/node_modules/"].

`coverageReporters` [array<string>] #

Por defecto: ["json", "lcov", "text"]

Tipos de reporte que Jest debe usar al realizar reportes de covertura. Cualquier tipo de reporte de istanbul puede ser usado.

Nota: Esta opción sobrescribe los valores por defecto. El valor "text" o "text-summary" debe ser agregado para ver el resumen de cobertura en consola.

`coverageThreshold` [object] #

Por defecto: undefined

Utilizado para imponer el mínimo de cobertura necesario. Si éste mínimo no se cumple, Jest regresará falla en su resultado. Si el valor se define como un número positivo, se tomará como el porcentaje de cobertura mínimo requerido. Si se especifica como un número negativo, representa el máximo número de entidades no cubiertas que se permiten.

Por ejemplo, statements: 90 indica que la cobertura mínima de sentencias es del 90%. Mientras que statements: -10 indica que no se permiten más de 10 sentencias no cubiertas.

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

`globals` [object] #

Por defecto: false

Conjunto de variables globales que necesitan estar disponibles en todos los ambientes de pruebas.

El ejemplo siguiente creará una variable global __DEV__ con valor true en todos los ambientes de pruebas:

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

Es importante notar que si se especifica un valor de referencia global aquí (como un objecto o un arreglo), y el código de alguna prueba modifica este valor, estos cambios NO se verán reflejados en pruebas que residan en otros archivos.

`mapCoverage` [boolean] #

disponible en Jest 20.0.0+ #

Por defecto: false

Al hacer el análisis de cobertura, Jest compara el código fuente original del proyecto con mapas de código emitidos por transformers definidos en la configuración. Estos son usados para la creación de reportes y la comparación de umbrales minimos. Esto se realiza con base en el mejor esfuerzo posible, pues algunos lenguajes que compilan a Javascript pueden proveer mapas de código fuente más acertados que otros. Este proceso puede también hacer uso intensivo de los recursos. Se puede reducir el tiempo que Jest toma para realizar el reporte de cobertura, cuando este sea tardado, estableciendo este campo como false.

Jest soporta mapas de código tanto in-line como aquellos regresados por transformers. Mapas de código en URLs no son soportados pues no hay garantía que Jest sea capaz de localizarlos. Para regresar mapas de código desde un transformador, la función process puede regresar un objeto como el siguiente. Donde la propiedad map puede ser el objeto del mapa de código, o un string JSON.

return {
  code: 'el código',
  map: 'el mapa de código fuente',
};

`moduleFileExtensions` [array<string>] #

Por defecto: ["json", "lcov", "text"]

Arreglo de extensiones de archivo que ocupen los módulos del proyecto. Si no se especifica ninguno, Jest buscará en los siguientes tipos de archivos.

Si se ocupa Typescript el arreglo sería ["js", "jsx", "json", "ts", "tsx"]

`moduleDirectories` [array<string>] #

Por defecto: ["/node_modules/"]

Arreglo de directorios a ser buscados desde la ubicación del modulo requerido de manera recursiva hacia arriba. Al asignarle un valor a esta opción se sobrescribe la opción por defecto. Si se desea que también se busquen paquetes en node_modules se debe incluir junto con las otras opciones deseadas: ["node_modules", "bower_components"]

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

Por defecto: null

Mapa de expresiones regulares que empatan a nombres de módulos que permitan ignorar recursos como imágenes o estilos a través de un modulo individual.

Módulos que se definan a través de un alias no son sustituidos, independientemente de si se ha activado la opción de simulación automática automocking.

Se debe usar la cadena <rootDir> para referirse al directorio raíz rootDir en donde se definan rutas.

De manera adicional, se pueden sustituir grupos de captura de expresiones regulares ocupando referencias anteriores numeradas.

Ejemplo:

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

Nota: Usar nombres de modulo sin los limites ^$ dificulta el encontrar errores. Por ejemplo, relay reemplazará todos los módulos que contengan relay como parte del nombre: tanto relay, react-relay y graphl-relay apuntarán al modulo de sustitución.

`modulePathIgnorePatterns` [array<string>] #

Por defecto: []

Arreglo de patrones de expresiones regulares regexp con los que se comparan las rutas a los módulos. Aquellos módulos que empaten son visibles para el cargador de módulos. Cualquier modulo cuya ruta empate con una expresión no podrá ser cargado vía require() en el ambiente de pruebas.

`modulePaths` [array<string>] #

Por defecto: []

API alternativa para asignar valor a la variable de ambiente NODE_PATH, modulePaths es un arreglo de rutas absolutas que apuntan a ubicaciones adicionales a ser buscadas al momento de resolver módulos. La cadena <rootDir> puede usarse para referir a la ruta al directorio raíz del proyecto. Ejemplo: ["<rootDir>/app/"].

`notify` [boolean] #

Por defecto: false

Activa notificaciones para los resultados de pruebas.

`preset` [string] #

Por defecto: undefined

Variable usada para definir la base de la configuración de Jest. Debe apuntar a un modulo npm que exporte un jest-preset.json en su nivel superior.

`projects` [array<string>] #

Por defecto: undefined

Cuando la opción projects se le asigna un arreglo de paths o patrones glob, Jest ejecutará pruebas en todos los proyectos especificados a la vez. Esto es ideal para mono-repositorios o cuando se trabaja en múltiples proyectos a la vez.

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

Este ejemplo de configuración ejecuta a Jest en el directorio root así como en cualquier directorio dentro de examples. Se puede tener una cantidad ilimitada de proyectos que se ejecuten por la misma instancia de Jest.

`clearMocks` [boolean] #

Por defecto: false

Borra automáticamente las llamadas a mocks e instancias entre cada prueba. Equivalente a llamar jest.clearAllMocks() entre cada prueba. Esto no remueve ninguna implementación de mock que se haya proporcionado.

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

Por defecto: undefined

disponible en Jest 20.0.0+ #

Se utiliza esta opción para agregar reporters personalizados a Jest. Un reporter personalizado es una clase que implementa los metodos onRunStart, onTestStart, onTestResult,onRunComplete los cuales se ejecutan cuando el evento correspondiente ocurre.

Si se especifican reporters personalizados, los reporters por defecto de Jest serán anulados. Para mantener los reporters por defecto, se debe pasar el argumento default como nombre de un módulo.

Esto anulará a los reporters por defecto:

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

Esto agregará reporters personalizados junto con los reporters por defecto que Jest provee:

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

De manera adicional, los reporters personalizados se pueden configurar pasando como segundo argumento un objeto options:

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

Los módulos de reporters personalizados deben definir una clase que toma la configuración global GlobalConfig y opciones de reporter como argumentos en el constructor:

Ejemplo de 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;

Los reporters personalizados pueden forzar a Jest a terminar con un código diferente a cero si regresan un Error en los métodos getLastError()

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

types/TestRunner.js contiene la lista completa de métodos y argumentos para el tipo Reporter

`resetMocks` [boolean] #

Por defecto: false

Restablece automáticamente el estado de los mocks entre cada prueba. Equivalente a llamar jest.resetAllMocks() entre cada prueba. Esto causa que todos los mocks tengan sus implementaciones falsas removidas sin restaurar su implementación inicial.

`resetModules` [boolean] #

Por defecto: false

Si se establece como true, el registro de módulos de cada archivo de prueba se restablecerá antes de ejecutar cada prueba. Esto es útil para aislar módulos entre pruebas y evitar conflictos entre el estado del modulo local de cada prueba. También se puede obtener el mismo resultado en código usando jest.resetModules().

`resolver` [string] #

Por defecto: undefined

disponible en Jest 20.0.0+ #

Permite ocupar un resolver diferente. El resolver debe ser un modulo de node que exporte una función. Dicha función debe esperar la ruta a resolver en forma de string como primer argumento, y la siguiente estructura como segundo argumento:

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

La función debe devolver una ruta al módulo a resolver o un error si no se encuentra dicho módulo.

`rootDir` [string] #

Por defecto: La raíz del directorio que contiene el archivo package.json o el pwd si no se encuentra el archivo package.json

El directorio raíz a utilizar por Jest para buscar tests y módulos. Si se desea configurar a Jest dentro del archivo package.json del proyecto y que el directorio raíz apunte al directorio del repositorio del proyecto, el valor de este parámetro tomará como valor por defecto el directorio donde se encuentre el package.json.

Comúnmente esta opción tomará el valor de 'src' o 'lib, dependiendo donde se encuentre el código en el repositorio del proyecto.

Es importante notar que cualquier otra opción que ocupe la cadena <rootDir> hará referencia al valor de esta opción. Por ejemplo, si se desea que la opción setupFiles apunte al archivo env-setup.js ubicado en la raíz del proyecto, se le debe asignar el valor ["<rootDir>/env-setup.js"].

`roots` [array<string>] #

Por defecto: ["<rootDir>"]

Una lista de rutas a directorios que Jest usará para buscar archivos.

Se puede ocupar para casos en donde se desea que Jest busque solamente en un sub-directorio (por ejemplo cuando existe un directorio src/ en el repositorio), y que no acceda al resto del repositorio.

Nota: Mientras que rootDir es ocupado generalmente como una constante en varias opciones de configuración, roots es usado por Jest internamente para encontrar archivos de prueba y de código fuente. Por defecto, roots tiene una sola entrada con valor <rootDir>. En casos donde se desee tener más de una raíz en el proyecto, se pueden agregar a la opción: roots:["<rootDir>/src/", "<rootdir>/tests/"].

`setupFiles` [array] #

Por defecto: []

Las rutas a módulos que ejecuten código de configuración o de preparación al framework de pruebas que deba ejecutarse antes de cada prueba. Ya que cada prueba es ejecutada en su propio ambiente, estos scripts serán ejecutados en cada ambiente inmediatamente antes de ejecutar el código de la prueba.

Es importante notar que este código se ejecutará antes que setupTestFrameworkScriptFile.

`setupTestFrameworkScriptFile` [string] #

Por defecto: undefined

La ruta de acceso a un módulo que ejecuta código para configurar o crear el ambiente de pruebas antes de cada prueba. Debido a que setupFiles es ejecutado antes de que se instale el framework de pruebas en el ambiente, este script presenta la oportunidad de ejecutar código inmediatamente después que el framework de pruebas ha sido instalado en el ambiente.

Por ejemplo, Jest contiene diferentes plug-ins de jasmine que se modifican la API de Jasmine sólo en la instancia donde se prueba. Si se desea agregar aún más plug-ins de Jasmine (o por ejemplo, si se desearan agregar funciones de match a ser usados en todo el proyecto), esto se podría realizar sobre este modulo.

`snapshotSerializers` [array<string>] #

Por defecto: []

Lista de rutas que apuntan a módulos de serialización de snapshots que Jest puede ocupar para pruebas de snapshot.

Jest internamente tiene serializadores para tipos de Javascript, elementos HTML (Jest 20.0.0+), ImmutableJS (Jest 20.0.0+) y otros elementos de React. Véase el tutorial de pruebas de snapshot para más información.

Ejemplo de modulo serializador:

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

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

};

serialize es una función que serializa un valor usando plug-ins existentes.

Como ejemplo, para usar un modulo llamado my-serializer-module como un serializador, la configuración es la siguiente:

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

Y finalmente, las pruebas se ven así:

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

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

Snapshot producido:

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

Para llamar a una dependencia de manera explicita en lugar de implícita, se puede ocupar expect.addSnapshotSerializer para agregarlo a un sólo archivo de prueba en lugar de agregar la ruta en snapshotSerializers de la configuración de Jest.

`testEnvironment` [string] #

Por defecto: "jsdom"

Ambiente de pruebas a utilizar. El ambiente por defecto en Jest es similar a un navegador a través de jsdom. Si se esta construyendo un servicio de node, se puede usar el valor node para utilizar un ambiente similar al de node.

En caso se requiera otro tipo de ambiente, se puede agregar en el bloque de código de @jest-environment.

disponible en Jest 20.0.0+ #

/**
 * @jest-environment jsdom
 */

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

Se pueden crear módulos personalizados para preparar un ambiente de pruebas. Estos módulos deben exportar una clase con los métodos runScript y dispose. Véase anode o jsdom como ejemplos.

`testMatch` [array<string>] #

disponible en Jest 19.0.0+ #

(por defecto: ['**/__tests__/**/*.js?(x)', '**/? (*.)(spec|test).js?(x)'])

Patrones glob que Jest usa para detectar archivos. Por defecto Jest busca archivos .js y .jsx dentro de directorios __tests__, así como cualquier otro archivo con los sufijos .test o .spec. (por ejemplo, Component.test.js o Component.spec.js). También encuentra archivos llamados test.js o spec.js.

Véase el paquete micromatch para detalles sobre los patrones validos.

Véase también testRegex[string], pero es importante notar que no se pueden especificar ambas opciones a la vez.

`testPathIgnorePatterns` [array<string>] #

Por defecto: ["/node_modules/"]

`testRegex` [string] #

Por defecto: (/__tests__/.*|(\\.|/)(test|spec))\\.jsx?$

Patrón utilizado por Jest para detectar archivos de prueba. Por defecto Jest busca archivos .js y .jsx dentro de directorios __tests__, así como cualquier otro archivo con los sufijos .test o .spec. (por ejemplo, Component.test.js o Component.spec.js). También encuentra archivos llamados test.js o spec.js. Véase también testMatch[array<string>], pero es importante notar que no se pueden especificar ambas opciones a la vez.

A continuación se muestra una visualización de la expresión regex por defecto:

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

`testResultsProcessor` [string] #

Por defecto: undefined

Esta opción permite el uso de un procesador de resultados personalizados. Este procesador debe ser un módulo node que exporta una función que a su vez espera un objeto con la siguiente estructura como su primer 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 (mensaje en el bloque it),
      "status": "failed" | "pending" | "passed",
      "ancestorTitles": [string (mensaje en los block describe)],
      "failureMessages": [string],
      "numPassingAsserts": number
    },
    ...
    ],
    "perfStats": {
      "start": epoch,
      "end": epoch
    },
    "testFilePath": ruta absoluta al archivo de prueba,
    "coverage": {}
  },
  ...
  ]
}

`testRunner` [string] #

Por defecto: jasmine2

Esta opción permite especificar el modulo que ejecuta las pruebas. El ocupado por defecto es jasmine2. Un modulo personalizado puede especificarse a través de una ruta que apunte a una implementación.

El modulo que ejecuta pruebas debe exportar una función con la siguiente estructura:

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

Un ejemplo de tal función puede encontrarse en el modulo por defecto jasmine2.

`testURL` [string] #

Por defecto: about:blank

Esta opción establece la dirección URL para el ambiente jsdom. Se refleja en ciertas propiedades como location.href.

`timers` [string] #

Por defecto: real

Establecer este valor como fake permite el uso de temporizadores falsos para funciones tales como setTimeout. Los temporalizadores falsos son útiles cuando un fragmento de código establece un largo tiempo de espera que se desea omitir al probar.

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

Por defecto: undefined

Mapa de expresiones regulares que apuntan a rutas de transformers. Un transformer es un modulo que provee una función sincrona para la transformación de archivos de código fuente. Por ejemplo, si se desea poder utilizar una nueva característica del lenguaje en algún modulo o en archivos de pruebas que todavía no está soportada por node, se puede ocupar un transpilador de una versión nueva de JavaScript a una anterior como plug-in. Ejemplo: veáse examples/typescript o el tutorial de webpack.

Ejemplos de dichos transpiladores incluyen a babel, typescript, y async-to-gen.

Nota: los transformadores se ejecutan una sola vez por archivo, a menos que el archivo haya cambiado. Cuando se desarrollan transformers, es buena practica correr Jest con --no-cache o borrar el caché de Jest frecuentemente.

Nota: Si en el proyecto se esta usando el transformer babel-jest y se desea usar un pre-procesador de código adicional, es importante notar que cuando "transform" es sobreescrito babel-jest deja de ser cargado automáticamente. Si se desea utilizar para compilar código JavaScript, este tiene que ser definido de manera explicita. Véase babel-jest-plugin

`transformIgnorePatterns` [array<string>] #

Por defecto: ["/node_modules/"]

Arreglo de patrones de expresiones regulares regexp con el que se comparan todos los directorios de código fuente del proyecto antes de transformarlo. Cualquier archivo que empate con la expresión no será transformado.

`unmockedModulePathPatterns` [array<string>] #

Por defecto: []

Arreglo de expresiones regulares regexp con el que se comparan todos los módulos antes de que el cargador de módulos regrese automáticamente un modulo simulado mock para estos. Cualquier modulo cuya ruta empate con algún patrón en la lista no será simulado automáticamente por el cargador de módulos.

Esto es particularmente útil para modulos de 'utilidad' que se frecuentemente se ocupan para detalles de implementación (como underscore/lo-dash, etc). Es considerado como buena practica minimizar el tamaño de esta lista y utilizar jest.mock()/jest.unmock() en cada prueba de manera individual. Hacer estas llamadas en cada prueba facilita a otros desarrolladores el entender el ambiente en el que se corre cada prueba.

Es posible sobrescribir el valor de esta opción en cada prueba de manera individual llamando jest.mock() al inicio de cada archivo de prueba.

`verbose` [boolean] #

Por defecto: false

Indica si cada prueba individual debe reportar su resultado durante la ejecución. Independiente de esto todos los errores siempre se muestran al final de la ejecución.

Opciones #

Referencia #

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] #

disponible en 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]>] #

disponible en Jest 20.0.0+ #

resetMocks [boolean] #

resetModules [boolean] #

resolver [string] #

disponible en Jest 20.0.0+ #

rootDir [string] #

roots [array<string>] #

setupFiles [array] #

setupTestFrameworkScriptFile [string] #

snapshotSerializers [array<string>] #

testEnvironment [string] #

disponible en Jest 20.0.0+ #

testMatch [array<string>] #

disponible en 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] #