Acortar las ejecuciones de Jest localmente y en CI: Workers, caché y ámbito

Un conjunto de pruebas lento modifica silenciosamente la forma en que trabaja un equipo: las personas ejecutan pruebas con menos frecuencia, envían los cambios a CI para averiguar el resultado y esperan el mayor tiempo justo cuando menos pueden permitírselo, durante una corrección de emergencia en producción. Ese costo aumenta cuando los asistentes de programación basados en IA generan cambios rápidamente y el conjunto de pruebas se convierte en la principal red de seguridad. Jest incluye muchas opciones de configuración y valores predeterminados razonables, por lo que la experiencia inicial suele ser adecuada, pero unos pocos ajustes pueden reducir significativamente los tiempos de ejecución tanto en una computadora portátil como en CI. Ninguno de ellos es exótico; juntos forman una lista de verificación útil.

Mida antes de ajustar

Cada cambio tiene un costo o una contrapartida, así que comience con cifras. Mida el tiempo de ejecución completo con la caché desactivada (jest --no-cache) para obtener una línea de referencia inicial, luego aplique un cambio a la vez y vuelva a medir.

Ajuste el paralelismo según la máquina

Por defecto, Jest ejecuta los archivos de prueba en procesos trabajadores paralelos, lo cual suele ser bueno, pero no siempre óptimo. Dos flags lo controlan:

• --runInBand ejecuta todas las pruebas de forma secuencial en el proceso actual sin trabajadores. Esto puede ser más rápido para proyectos del lado del servidor cuyas pruebas comparten un recurso costoso, o en ejecutores de CI con muy pocos núcleos, donde crear trabajadores cuesta más de lo que ahorra.
• --maxWorkers establece cuántos trabajadores genera Jest. Acepta un número o un porcentaje de los núcleos disponibles; 50% es un punto de partida razonable que deja espacio para el resto de la máquina.

El valor adecuado depende del hardware, por lo que hay que medirlo localmente y en los ejecutores de CI por separado. Las máquinas de CI a menudo indican más núcleos de los que pueden utilizar realmente bajo carga, y sobresuscribirlos hace que las pruebas sean más lentas, no más rápidas.

Mantén la configuración global ligera

Un archivo de configuración global es útil en una gran base de código: se registran los mocks, polyfills y utilidades de prueba una sola vez, y cada prueba los recibe. El problema es que cada archivo de prueba paga por todo ello, incluidos aquellos que no los necesitan. Importaciones pesadas, fixtures de base de datos o grandes registros de mocks en setupFilesAfterEnv pueden convertir pruebas unitarias que normalmente son rápidas en milisegundos en pruebas lentas.

Mueve la configuración costosa más cerca de las pruebas que la necesitan: un helper importado explícitamente, un beforeAll en el archivo correspondiente, o un proyecto Jest separado con su propia configuración para pruebas de integración.

Reutiliza la caché

Las segundas ejecuciones suelen ser más rápidas que las primeras porque Jest almacena en caché los archivos transformados y otros metadatos. Esto se nota especialmente en el modo de vigilancia, pero también beneficia al CI si el caché persiste entre tareas. Dirija cacheDirectory a una ruta estable y consérvela mediante la función de caché de su sistema CI, utilizando como clave el archivo de bloqueo y la configuración de Jest, para que cada pipeline no comience desde cero.

Usar el modo de vigilancia localmente

Para trabajar localmente, jest --watch es el mejor ciclo de retroalimentación que ofrece Jest. Vuelve a ejecutar solo las pruebas relacionadas con los archivos modificados, y su prompt interactivo le permite filtrar por nombre de archivo o patrón de nombre de prueba. No está diseñado para el CI: un pipeline necesita una sola ejecución que finalice con un código de estado, por lo que mantenga el modo de vigilancia en las máquinas de los desarrolladores.

Habilitar isolatedModules para TypeScript

Cuando las pruebas de TypeScript se ejecutan con ts-jest, la verificación completa de tipos en cada archivo genera una carga adicional considerable. Al activar isolatedModules, el transformador compila cada archivo por separado, sin la información de tipos del resto del programa. Los equipos han reportado mejoras significativas en la velocidad en proyectos Angular, y se pierde muy poca seguridad siempre y cuando tsc --noEmit o el editor siga verificando los tipos del código. La ubicación exacta de esta opción depende de la versión de ts-jest, por lo que es necesario consultar su documentación actual.

Pruebe solo aquello que se ve afectado por un cambio

No hay razón para ejecutar todo el conjunto de pruebas por un cambio que afecta a un solo paquete. Jest mismo puede restringir la ejecución con --onlyChanged o --changedSince=<branch>, opciones que utilizan el control de versiones para encontrar las pruebas relacionadas. En un monorepo, un sistema de construcción como Nx va aún más allá al comprender el grafo del proyecto y ejecutar pruebas solo para aquellos proyectos afectados por el cambio actual.

Mantenga al menos una ejecución completa en algún lugar, por ejemplo en la rama principal o de forma nocturna, para detectar cualquier cosa que la análisis de dependencias pueda pasar por alto.

Considere Vitest

Vitest es en gran medida compatible con la API de Jest, está actualizado activamente y funciona con los frameworks JavaScript más comunes, incluido Nuxt. Para proyectos ya desarrollados con Vite, a menudo es la opción más natural, y muchos equipos lo eligen primero en nuevos proyectos. La mayoría de los consejos anteriores, como la medición, los límites de los workers, una configuración ligera y la ejecución únicamente de las pruebas afectadas, también son aplicables a Vitest. Si está considerando eliminar por completo un ejecutor de terceros, consulte cómo reemplazar Jest por el ejecutor de pruebas nativo de Node.

Cuando ya no sirven los ajustes del software

Al final, ningún cambio de configuración supera a un hardware más rápido. Una laptop más nueva o un ejecutor CI propio y de mayor capacidad pueden ser la mejor mejora económica una vez que el conjunto de pruebas en sí esté bien estructurado.

Puntos clave

• Establezca una línea de base fría y sin caché, y cambie una cosa a la vez.
• Ajuste --maxWorkers o --runInBand según la capacidad real de cada entorno.
• Retire las configuraciones costosas de los hooks globales y póngalas en las pruebas que las necesitan.
• Conservar el caché de Jest entre ejecuciones de CI; use el modo de vigilancia solo localmente.
• Deje que isolatedModules omita la verificación de tipos por archivo, mientras que un paso separado con tsc mantiene la precisión de los tipos.
• Ejecute solo las pruebas afectadas en las ramas de características, y un conjunto completo en la rama principal.

Lecturas relacionadas

• Sustituyendo Jest por el ejecutor de pruebas nativo de Node en Node 24 — Una migración real muestra cómo el ejecutor de pruebas integrado en Node 24 y el soporte nativo para TypeScript reducen el tiempo de CI al mismo tiempo que eliminan cuatro dependencias.

Una lista de verificación para la revisión de código en React: estado derivado, reductores, Effects y Memo — Aprenda a identificar siete problemas comunes en las revisiones de código en React, desde estado duplicado y obtención de datos manual hasta uso incorrecto de Effects y memorización excesiva, y qué escribir en su lugar.