Jest 15.0: Nuevas Configuraciones Predeterminadas para Jest

Traducción Beta No Oficial

Esta página fue traducida por PageTurner AI (beta). No está respaldada oficialmente por el proyecto. ¿Encontraste un error? Reportar problema →

Hemos pasado el último año haciendo que Jest sea más rápido, más fácil de configurar, añadiendo toneladas de funciones y construyendo pruebas de instantáneas. Sin embargo, hubo dos áreas en las que invertimos muy poco: la salida de la CLI y la experiencia de usuario. Con Jest 15 estamos cambiando radicalmente el marco para hacerlo más fácil de usar tanto para principiantes como para usuarios experimentados. Estamos emocionados de que nuestra inversión en Jest ahora dé frutos: podemos avanzar rápido y mejorar el marco para Facebook y la comunidad de código abierto a la velocidad de la luz. El objetivo de Jest es venir con "baterías incluidas" y requerir la menor configuración posible. Recientemente tuvimos la oportunidad de explicar nuestra filosofía en un issue de create-react-app.

El cambio más importante del que hablar es un conjunto de nuevas configuraciones predeterminadas. Si ya usas Jest, es muy probable que necesites actualizar tu configuración para Jest 15. En la mayoría de los casos esto simplificará tu configuración y Jest proporcionará mensajes de error útiles durante la actualización. Todas las nuevas configuraciones predeterminadas se pueden desactivar según tus necesidades, pero seguimos considerando estas funciones desactivadas como críticas para Jest en ciertas situaciones y continuaremos usándolas y dándoles soporte en Facebook a largo plazo. Nuestra documentación de API también se reescribió completamente para reflejar estos cambios. Esta solicitud de extracción para React destaca algunos de los cambios necesarios para proyectos existentes.

Nuevos mensajes de error y resúmenes en la CLI

Como parte de nuestro esfuerzo por eliminar Jasmine gradualmente dentro de Jest, reemplazar todos los comparadores de Jasmine está casi completo. Pasamos mucho tiempo ajustando cada mensaje de error para cada comparador para dar la mejor señal a los usuarios cuando una prueba falla, el momento en que Jest debería proporcionar el mayor valor. Además de imprimir los valores esperados y recibidos, se muestra una diferencia para los comparadores toBe y toEqual para ayudar a detectar errores. Se añadieron más colores y los archivos relevantes de los seguimientos de pila se destacan más prominentemente.

Aquí hay una comparación del antes y después en un terminal claro: También funciona bien con colores oscuros:

Nuevo comando watch

Reescribimos completamente jest --watch para que sea más interactivo. Ahora puede cambiar entre ejecutar todas las pruebas o solo los archivos de prueba relacionados con archivos modificados presionando a u o. Al presionar p, aparece un aviso que permite especificar un patrón de prueba para enfocarse en un conjunto específico de archivos. Las pruebas de instantáneas se pueden actualizar presionando u.

Mejoras en jest-react-native

Se añadieron simulacros para ListView, TextInput, ActivityIndicator, ScrollView y más. Los simulacros existentes se actualizaron para usar implementaciones reales y las instantáneas existentes probablemente deban actualizarse al pasar a Jest 15. Se añadió una función mockComponent a jest-react-native que se puede usar para simular componentes nativos:

jest.mock('MyNativeComponent', () => {
  const jestReactNative = require('jest-react-native');
  return jestReactNative.mockComponent('MyNativeComponent');
});

También ha habido varias mejoras en la simulación de imágenes, el módulo fetch y otras APIs nativas.

Mensajes de Consola en Búfer

Jest paraleliza las ejecuciones de pruebas entre trabajadores para maximizar el rendimiento. Anteriormente, Jest solía reenviar mensajes de la consola desde los trabajadores al proceso principal e imprimirlos inmediatamente. Al ejecutar múltiples pruebas en paralelo, a menudo era difícil determinar qué prueba y qué módulo estaba llamando a una función de registro. En Jest 15, todos los mensajes de la consola se almacenan en búfer y se imprimen junto con los resultados individuales de las pruebas. Además, se imprime el archivo y número de línea de la llamada de registro para que el código se pueda inspeccionar fácilmente.

Compara la salida de la versión anterior de Jest y Jest 15:

Desactivación de la Autosimulación

La autosimulación (automocking) ahora está desactivada por defecto en Jest. Esta era sin duda la característica más confusa para nuevos usuarios y en muchos casos no tiene sentido para proyectos pequeños. Introdujimos la autosimulación en Facebook y funcionó excelente cuando adoptamos pruebas unitarias en una base de código grande con pocas pruebas existentes, pero con el tiempo notamos que la gente dedicaba más tiempo lidiando con módulos simulados/no simulados que escribiendo pruebas normalmente. También observamos que los autores de bibliotecas frecuentemente requieren muchos módulos básicos que siempre deben desactivarse manualmente. Incluso en Jest mismo, la mayoría de pruebas tenían la autosimulación desactivada manualmente. Seguimos creyendo que la autosimulación explícita puede ser increíblemente valiosa. Este cambio simplemente reemplaza las simulaciones implícitas por explícitas mediante llamadas a jest.mock(moduleName).

Si aún deseas usar autosimulación por defecto, habilita la opción automock en tu configuración o llama manualmente a jest.enableAutomock() en tu archivo de pruebas o setup.

Patrones de Archivos de Prueba

No todos usan la misma convención de carpeta __tests__ para almacenar pruebas. Jest 15 también busca archivos terminados en .spec.js o .test.js, dos estándares populares en la comunidad. Jest 15 elimina además las opciones de configuración testDirectoryName y testFileExtensions, pidiendo a los usuarios que usen la opción testRegex cuando se usen las antiguas configuraciones.

Persistencia del Registro de Módulos

Jest solía reiniciar implícitamente todos los módulos antes de cada prueba y recomendábamos requerir módulos en beforeEach o dentro de las pruebas. Esto es útil cuando los módulos tienen estado local que no debería compartirse entre pruebas. Sin embargo, ocurrieron dos grandes cambios: los módulos ES con sintaxis import de nivel superior y un renovado interés en escribir módulos funcionales sin estado.

Esto generó numerosas incompatibilidades. También notamos que en Facebook ni siquiera usábamos este reinicio implícito. En su lugar, dependíamos de llamadas explícitas a jest.resetModules(), lo que da a los ingenieros control sobre cuándo borrar todo el estado.

Aquí un ejemplo:

const React1 = require('react');
jest.resetModules();
const React2 = require('react');

React1 !== React2; // These two are separate copies of React.

La llamada a resetModules borra la caché de require. Una segunda llamada para requerir el mismo módulo resultará en una nueva instanciación del mismo módulo y todas sus dependencias. Esta característica es especialmente útil cuando se trabaja con módulos que tienen efectos secundarios, como jest-haste-map.

Creemos que es mejor dar control a los usuarios, así que desactivamos el reinicio implícito. Los módulos pueden reiniciarse usando jest.resetModules() en el código, y la opción resetModules puede habilitarse en la configuración para recuperar el comportamiento anterior.

Temporizadores Reales vs. Simulados

Por defecto, Jest solía simular funciones temporizadoras como setTimeout o process.nextTick, ofreciendo una API jest.runAllTimers() para avanzar temporizadores programáticamente. Esto es útil cuando un código establece un tiempo de espera largo que no queremos esperar en una prueba.

Sin embargo, encontramos que en la mayoría de casos los usos están muy aislados. La programación asíncrona también se ha simplificado en nuestro ejecutor de pruebas. Jest ahora usa temporizadores reales por defecto.

Puedes anular esto especificando "timers": "fake" en la configuración o usando los interruptores globales jest.useRealTimers() y jest.useFakeTimers().

setupEnvScriptFile vs setupFiles

La opción de configuración setupEnvScriptFile ha estado obsoleta por un tiempo. Jest 15 la elimina completamente y la reemplaza con setupFiles. Esta opción espera un array de rutas de archivo que se cargan en orden antes de ejecutar un archivo de prueba.

Soporte de Cobertura de Código Reescrito

La cobertura de código en Jest se puede utilizar mediante jest --coverage y no requiere paquetes adicionales ni configuración. El soporte de cobertura de código se reescribió por completo y se añadió una nueva opción collectCoverageFrom para recopilar información de cobertura de proyectos completos, incluyendo archivos no probados. Ten en cuenta que esta opción utiliza globs, ya que esperamos simplificar aún más las opciones de configuración en el futuro y ofrecer una alternativa más sencilla a las expresiones regulares. Consulta el package.json de Jest para ver un ejemplo.

Otras mejoras

También se realizaron una gran cantidad de otras mejoras:

• Rendimiento mejorado en ejecuciones de pruebas pequeñas.

• Jest ahora usa modo detallado cuando se ejecuta un único archivo de pruebas.

• Se añadió la opción --env para sobrescribir el entorno de pruebas configurado.

• moduleNameMapper ahora utiliza un algoritmo de resolución.

• Jest ahora funciona con rutas que contienen caracteres especiales, como paréntesis.

• Se añadió global.global al entorno de Node.

• Se corrigió el error inválido de babel-plugin-jest-hoist cuando una función de usuario aleatoria se llamaba mock.

• Corrección en la resolución de testEnvironment para preferir jest-environment-{name} en lugar de solo {name}. Esto evita colisiones de módulos al usar jsdom como entorno de pruebas.

• Mejoras en la infraestructura de pruebas de Jest mediante la fusión de pruebas de integración y unitarias. Ahora se recopila cobertura de código para Jest.

Estamos satisfechos al repasar todos los cambios que hemos realizado con la ayuda de la comunidad y no podríamos estar más emocionados de seguir mejorando Jest en los próximos meses. Por favor, reporta un problema si algo no funciona como se espera y envíanos pull requests.

Próximamente: Concurrent Reporter.