Jest: Jest es 3 veces más lento en todas las máquinas con Windows (Windows 10 y versiones inferiores)

Relacionado: # 6783

¿Se inicia lentamente o también en modo reloj? Si solo durante el inicio, puede intentar instalar watchman , eso debería ayudar (https://facebook.github.io/watchman/docs/install.html)

Cuando está pasando por las pruebas, parece estar bien de ahí en adelante (EDITAR: En realidad, también es más lento cuando se ejecutan las pruebas. Pasa una por una a la velocidad de 0.5 segundos mientras que la norma se siente como 0.05
segundos por prueba)
Sin embargo, es lento para iniciar y / o iniciar pruebas de broma (aproximadamente 4-6 segundos de retraso, 4-6 veces más lento que las máquinas mac)

Intentaré vigilante y te responderé

Si pudieras crear un perfil usando, por ejemplo, ndb el inicio y descubrir qué es lento, también sería de gran ayuda

El retraso sigue siendo lento incluso con vigilante instalado.
Ejecuté una prueba de creación de perfiles con ndb ejecutando "jest --verbose", aquí están los resultados:

Captura de pantalla de los primeros 1,7 segundos:

Captura de pantalla de 1.8 segundos a 2.7 segundos

Un archivo .json y un archivo .heapsnapshot guardados desde la pestaña de perfil en ndb después de la grabación:

profiling.zip

@pfftdammitchris ¿cuál es su caso de uso [exacto] en el que notó la lentitud?
(un archivo o varios archivos)? (modo reloj o no)? ¿Puede proporcionar el ejemplo.
para un problema de modo de visualización de archivos => por favor lea mi último comentario en: # 6783

Es lento para archivos únicos y múltiples, con o sin modo de reloj. Prácticamente cada vez que ejecuta cualquier prueba, hay un retraso de más de 3 segundos en la inicialización de las pruebas, y la ejecución de las pruebas una por una en 0.3 o 0.4 o 0.5 segundos es lenta, mientras que otros corredores de prueba como mocha / chai generalmente simplemente se ejecutan cada uno como si se sintiera como 0.05 segundos cada uno.

Utilizo jest en codesandbox y parecen ejecutar jest instantáneamente en la inicialización / ejecución de pruebas, vi a mis compañeros de trabajo ejecutar jest en sus máquinas Mac y lo ejecutan instantáneamente como normalmente. Hasta donde yo sé, son solo máquinas de Windows. Utilizo una máquina con Windows en el trabajo y Jest está teniendo el problema lento allí, y también uso una máquina con Windows en casa y el problema continúa aquí.

Usé --runInBand, pero parecía haber ralentizado ligeramente las pruebas unitarias en 0,2 segundos adicionales cada una, según la sensación.

Aclaración

Usé --runInBand, pero parecía haber ralentizado ligeramente las pruebas unitarias en 0,2 segundos adicionales cada una, según la sensación.

=> ¿Intentaste con v24? de v23 a v24, verá una buena mejora SOLAMENTE para este escenario:
_en el rerun con watch y solo si se ejecuta contra un archivo (no en la primera ejecución) _
-> 2/3 seg. Caída a 0,4 / 0,5 seg.
pero en comparación con mac nunca lo probé ... así que tal vez todavía sea malo ... incluso con la mejora actual

@SimenB

1. Considero https://github.com/facebook/jest/issues/7110 como regresiones de velocidad de Jest [v22 vs v23] en Windows para TODOS los escenarios problemáticos.
   donde # 6783 es ​​uno de ellos

2. Puedo considerar este problema como: problema de velocidad para broma [Mac vs Windows] para TODOS los escenarios problemáticos.

Hola a todos !
Acumulo la lentitud de Jest 24 y Windows 10 (¡800 para 400 pruebas!). La forma más rápida que encontré para acelerar todo esto es usar wsl en lugar de powershell o cmd. Ahora mis pruebas toman "solo" 189s.

Tenemos un conjunto de 144 archivos de prueba con 1302 pruebas que tardan 1 minuto y 43 segundos en ejecutarse en una máquina con Windows 10 compilación 15063, Core i7 con 16 GB, y tardan 28 segundos en un MAC OS Mojave con 32 GB. Nuestro equipo de desarrollo está dividido equitativamente entre Windows y Mac y los números son muy repetibles.

Aquí hay una prueba simple:

it("works", () => {
  expect(1).toEqual(1);
});

Lo puse en codesandbox y se ejecuta casi al instante: https://codesandbox.io/s/4q8l0q52lw

en mi máquina con Windows, aunque tarda 4-5 segundos -

PASS src / index.test.js
v trabaja (62ms)

Grupos de pruebas: 1 aprobado, 1 en total
Pruebas: 1 aprobada, 1 total
Instantáneas: 0 en total
Tiempo: 4.158s
Ejecutó todas las suites de prueba.

La prueba en sí tomó 62 ms, pero el resto del arnés de prueba tomó 4 segundos. Volver a ejecutar la prueba presionando Enter toma la misma cantidad de tiempo.

Mi configuración -

> npx envinfo --preset jest

  System:
    OS: Windows 10
    CPU: (4) x64 Intel(R) Core(TM) i7-7500U CPU @ 2.70GHz
  Binaries:
    Node: 8.12.0 - C:\Program Files\nodejs\node.EXE
    Yarn: 1.10.1 - C:\Program Files (x86)\Yarn\bin\yarn.CMD
    npm: 6.4.1 - C:\Program Files\nodejs\npm.CMD

Lo probé con WSL Ubuntu y obtuve los mismos resultados (4-5 segundos) - esas configuraciones -

  System:
    OS: Linux 4.4 Ubuntu 18.04.2 LTS (Bionic Beaver)
    CPU: (4) x64 Intel(R) Core(TM) i7-7500U CPU @ 2.70GHz
  Binaries:
    Node: 8.10.0 - /usr/bin/node
    npm: 3.5.2 - /usr/bin/npm

Recién estoy comenzando con Jest, así que tengo pruebas bastante simples, y pueden tardar entre 15 y 20 segundos en ejecutarse. Me encantaría que funcionen rápidamente; de ​​lo contrario, tiendo a perder el hilo de mis pensamientos.

@bburns leer el problema anterior

@kensherman
puedes probar con micromatch 4 en tus resoluciones de hilo. para ver si queda mejor en windows por favor?
https://github.com/facebook/jest/issues/7963#issuecomment -483985345

Estoy en una MacBook Pro nueva. Como tengo estudiantes tanto en MacOS como en Windows 10, decidí agregar dos particiones más a mi disco; uno para Windows 10 y otro para almacenamiento compartido usando Tuxera NTFS.

Hoy me encontré con este problema de velocidad al preparar una lección de JavaScript que incorpora pruebas unitarias. De hecho, estoy ejecutando Jest desde MacOS, pero el código y las pruebas se encuentran en la partición NTFS compartida. Incluso con todas las suites marcadas como describe.skip , Jest tarda más de 10 segundos en completarse, tanto en los modos de ejecución única como de observación.

8 suites
42 pruebas

Cambié jest por mocha y chai y las carreras se redujeron a aproximadamente 1 segundo en modo de reloj sencillo y 10 milisegundos.

Cambié broma por mocha y chai y las carreras volvieron a bajar a aproximadamente 1 segundo en modo de reloj sencillo y 10 milisegundos.

Básicamente no leíste mi última publicación. Querías promover mocha/chai ... todos sabemos acerca de esto ... Estamos tratando de arreglar la regresión de broma. O ayudas a hacer esto [de mi publicación] ...can you try with micromatch 4... o mantienes estos comentarios inútiles fuera del hilo. Lamento ser directo, pero en algún momento no hay otra forma de decirlo.

@nasreddineskandrani Estoy probando [email protected] pero todavía puedo ver una ejecución extremadamente lenta cuando se ejecuta con el modo de reloj, cualquier ayuda sería muy apreciada.

@pachumon, la solución no está presente en 24.8.0 hasta donde tengo entendido

debe establecer una dependencia de jest a una versión específica para eliminar el problema de rendimiento (teóricamente) la solución estará presente de forma predeterminada en jest 25 => lea aquí para saber cómo un desarrollador descubre esto https://github.com/ facebook / jest / issues / 7963 # issuecomment -483985345

para configurar la dependencia (micromatch) a la versión donde se realizó la corrección => puede verificar aquí hice un ejemplo en un pequeño proyecto
https://github.com/nasreddineskandrani/benchmark_jest/blob/master/jest_24_with_micromatch4/package.json

Agregue a su package.json : (debe usar yarn no npm )

...
  "resolutions": {
    "micromatch": "^4.0.0"
  }
...

¡Espero que esto ayude! y esperando comentarios

El tiempo de ejecución de mi prueba también se ha disparado de ~ 2,5 minutos en 23.6.0 a ~ 15 minutos en 24.7.1 y 24.8.0. Nuestro servidor CI está ejecutando Windows y ha experimentado un aumento igualmente grande en el tiempo de construcción con esta actualización. Probé la anulación de la resolución de dependencia de micromatch como se mencionó anteriormente por @nasreddineskandrani sin éxito. Hágame saber si hay algo que pueda hacer para ayudar a diagnosticar esto.

@TomMahle esta es una noticia súper mala :( (la regresión de la que estamos hablando en la parte superior ya estaba en 23.6)
En este momento, un proyecto simple de "muestra" mostró un buen rendimiento. después de la actualización de micromatch.
Entonces necesitamos un proyecto problemático real para depurar, ¿su proyecto es privado? o publico?

Gracias por la sugerencia sobre micromatch @nasreddineskandrani , pero como @TomMahle arriba, fijarlo en ^4.0.0 tampoco pareció mejorar el rendimiento para mí. 😢

Sin embargo, descubrí una cosa curiosa que podría ayudar a diagnosticar este problema.

Tengo la capacidad de ejecutar broma en mi sistema nativo de Windows, en un contenedor Docker con el directorio principal de la aplicación montado desde mi sistema de archivos de Windows. La ejecución en modo sin vigilancia parece tener un comportamiento casi idéntico en ambos sistemas, lo que tal vez sugiera, como sugirió @thebearingedge , que el problema central tiene algo que ver con el sistema de archivos NTFS, ya que mi contenedor de ventana acoplable está ejecutando todo excepto el sistema de archivos en una máquina virtual linux.

Sin embargo, en el modo de observación, las cosas son ligeramente diferentes: las ventanas nativas siempre funcionan lentamente como se esperaba, pero el contenedor de la ventana acoplable solo ejecuta las pruebas lentamente en la primera ejecución . Una vez que le digo que ejecute cualquier conjunto de pruebas por segunda vez (por ejemplo, presionando py ingresando un patrón), ejecuta las pruebas en menos de un segundo (hacer lo mismo en Windows nativo toma 3-4 segundos). El único inconveniente de usar la ventana acoplable es que los eventos de cambio de archivo no parecen propagarse desde el volumen de mi Windows a la ventana acoplable, así que tengo que presionar manualmente Enter para volver a ejecutar la prueba en lugar de que bromee hacerlo automáticamente, pero supongo que eso es no es relevante para el tema en cuestión.

@nasreddineskandrani. Desafortunadamente mi proyecto es privado. Sin embargo, si hay ejemplos de código más pequeños (¿la configuración de broma?) O estadísticas que pueda proporcionar, me complace hacer eso. Todas las pruebas parecen ser dramáticamente más lentas (solo en Windows), así que no creo que tenga que ver con las pruebas específicas.

Estoy terminando un trabajo de Docker que estoy haciendo para mis sitios web personales -> después (en una semana) volveré sobre esto.

@TomMahle
Intentaré mi lado para tener un repositorio github con el problema que describe.

1. ¿Cuántas pruebas tienes?
2. ¿Está habilitando el modo dom para las pruebas?
3. es reaccionar o angular?
   prima:
4. ¿Puedes intentar reproducir el problema en un repositorio de github para poder depurar?
   puedes bifurcar la mía: https://github.com/nasreddineskandrani/benchmark_jest
   O
5. tal vez pruebe mi repositorio en su máquina de prueba? y ver los resultados? entre 23,6 y 24

Pensé que se había prestado suficiente atención a los mantenedores de micromatch, por lo que esto ya debe haber sido resuelto. Ejecutar (escribir así) pruebas de broma en Windows es una experiencia muy desagradable en este momento.

Me mudé a mocha / chai desde entonces, pero me sorprende que este problema todavía se esté trabajando.

Aclaración

Usé --runInBand, pero parecía haber ralentizado ligeramente las pruebas unitarias en 0,2 segundos adicionales cada una, según la sensación.

=> ¿Intentaste con v24? de v23 a v24, verá una buena mejora SOLAMENTE para este escenario:
_en el rerun con watch y solo si se ejecuta contra un archivo (no en la primera ejecución) _
-> 2/3 seg. Caída a 0,4 / 0,5 seg.
pero en comparación con mac nunca lo probé ... así que tal vez todavía sea malo ... incluso con la mejora actual

@SimenB

1. Considero el # 7110 como regresiones de velocidad de Jest [v22 vs v23] en Windows para TODOS los escenarios problemáticos.
   donde # 6783 es ​​uno de ellos

2. Puedo considerar este problema como: problema de velocidad para broma [Mac vs Windows] para TODOS los escenarios problemáticos.

Probé con ambas versiones en ese momento del post.

Acabo de crear un nuevo proyecto con una prueba con pruebas de inserción de matriz simples y me tomó más de 10 segundos desde el principio hasta el final. El proyecto usa react / typecript, pero el archivo de prueba no es un archivo de componente de reacción, sino un archivo normal como un .js. Gif a continuación para referencia visual si hace que sea mejor visualizar cuál podría ser el problema:

Noté que la primera vez que ejecuto la prueba, muestra que se estima que la prueba es de 9 segundos. Una vez que se completa, vuelve a intentar aleatoriamente las pruebas una segunda vez hasta su finalización.

Cuando tomé esa imagen gif de arriba (que fue la segunda vez esta vez), el tiempo estimado se redujo un poco y no se realizó un segundo reintento. No estoy seguro de si ese es el comportamiento de broma esperado.

Aquí hay un gif de mí ejecutando micromatch 4 con hilo en un proyecto separado:

El uso de Windows 10 y las especificaciones de mi computadora son:
Procesador AMD FX (tm) -8320 de ocho núcleos a 3,50 GHz
16 GB de RAM
x64
SSD

Déjame compartir mi perfil aquí.
Especificaciones:

• Windows 10 Pro
• Nodo 10.15.3
• Intel Core i7-4702MQ de 2,2 GHz
• 8 GB de RAM
• x64
• SSD

Pasos:

1. npx create-react-app my-app --typescript
2. cambiar App.test.tsx
3. ejecutar npm test

Perfil de CPU:

CPU-20190801T141211.zip

¿Se espera que se gasten 15 segundos solo con la solicitud de módulos para un solo componente y prueba trivial de React?

¿Alguien con más experiencia en la creación de perfiles de CPU puede echar un vistazo?

112 pruebas
ventanas 10
primera ejecución 507 segundos
segunda ejecución 23 segundos
subsistema linux
primera carrera 54 segundos
segunda ejecución 29 segundos

85 pruebas
ventanas 10
primera ejecución 44 segundos
segunda ejecución 15 segundos
subsistema linux
primera ejecución 26 segundos
segunda ejecución 15 segundos

Kepro estos resultados son con micromatch 4?

Prefiero el chat directo que tener un mensaje de 1 millón aquí, realmente se está volviendo un infierno de seguir cruzando todos los temas relacionados con el mismo tema.
Puedes unirte aquí. https://gitter.im/wearefrontend/jest-slow-windows
Estoy en eso ahora ...

Gitter está bloqueado por la VPN de mi empresa; si ustedes, amables personas, pudieran publicar actualizaciones significativas aquí, sería increíble <3

todavía puedes conectarte en casa para hacer algo de código abierto: P y verifícalo
ps, un juego de dota tarda más en hacer cola, ahora puedes comprobar gitter en este momento;)
aquí es donde está ahora: nodejs / node # 28946

@nasreddineskandrani Me tienes. He ordenado una nueva macbook, por lo que estaré fuera de la acción de código abierto hasta que llegue. Me niego a trabajar en mi caja de Windows de mierda en mi tiempo libre: D

Parece que el problema se ha trasladado al ámbito del nodo / C ++, que está un poco (extremadamente) fuera de mi zona de confort, ¡pero investigaré un poco!

Hola ¿alguna noticia sobre esto?

Como solución alternativa, puede usar --runInBand si comienza varias pruebas. Aún tardará mucho en comenzar la primera prueba, pero las próximas serán rápidas.

Mi proyecto tomó 21,803 para ejecutar todas las pruebas.
Ahora con --runInBand solo toma 7.412s

--runInBand para mí solo hazlo aún más lento. 1200 pruebas. Sin runinBand 70/50 segundos. Con --runInBand sus 90 segundos en segundas carreras en el mejor de los casos
En Linux es como 5-8 veces más rápido

Intente entonces --maxWorkers = 4.

@ cino893 , no es una solución :) intenta encontrar una solución, no una solución alternativa

¿Alguna noticia sobre eso? Apilé en la versión 21 debido a ese error. v22 es lento y v23 es aún más lento.
¿No creen que es un error de alta prioridad?

Donde yo trabajo, no tenemos la libertad de elegir el sistema operativo ni de instalar Ubuntu en Windows o algo similar.

@gombek, ¿has probado la v25? El equipo de Jest ha realizado muchas mejoras de rendimiento en todos los ámbitos.

Hola, pensé en agregar información adicional a esta discusión. Jest es muy lento también cuando se ejecuta dentro de un contenedor Docker que tiene el código fuente y las pruebas compartidas a través del volumen desde el sistema host (Windows).

Estoy bastante seguro de que esta ralentización se debe a las diferencias en la forma en que Windows maneja los archivos en comparación con los sistemas Unix. En Unix, si un proceso tiene un identificador de archivo abierto que no impide que otros procesos lean ese archivo. En Windows, un proceso que tiene un identificador de archivo es propietario de ese archivo siempre que lo libere. Buscaría en el código Jest la lógica de lectura de archivos y especialmente cuándo y cómo se liberan los identificadores de archivos. De todos modos, un programa que se comporte bien debería liberar los identificadores de archivos inmediatamente después de haber hecho su trabajo. De todos modos, el ejecutor de pruebas como Jest no debería tener ninguna razón para mantener el control del archivo durante mucho tiempo.

@gombek, ¿has probado la v25? El equipo de Jest ha realizado muchas mejoras de rendimiento en todos los ámbitos.

Estoy usando Jest v25 en Windows y todavía es lento

@pfftdammitchris He comparado suites de prueba bastante complejas en Mac + Windows y veo algunas diferencias, principalmente en una caché fría. Windows es notablemente más lento, pero una vez que hace calor, obtengo un rendimiento similar entre los dos.

SIN EMBARGO...

Una cosa de la que hay que tener mucho cuidado en Windows en particular son los programas intrusivos a nivel del núcleo como los antivirus / observadores de archivos como Carbon Black (u otro software de observación de archivos en tiempo real). Si tiene algo como esto en ejecución, puede ver GRANDES impactos de rendimiento al ejecutar Jest. Estoy hablando de que la ejecución de las pruebas lleva decenas de minutos.

Trabajé para una empresa el año pasado donde el mismo conjunto de pruebas tomó ~ 30 segundos en una Macbook Pro y 20 minutos en una computadora portátil con Windows con estos programas de observación de archivos en ejecución.

No tengo idea de por qué, pero me atrevería a adivinar que es algo que ver con los manejadores de archivos y cómo Jest usa algunas de las API del sistema de archivos node.js.

Solo tengo alrededor de 20 pruebas y acabo de tomar algunos tiempos con broma: observe, tanto en la ejecución inicial como luego presionando enter para volver a ejecutarlas.

En Windows, tomó alrededor de 15 segundos en ambas ocasiones, mientras que para Linux fue de alrededor de 5.3 segundos para la primera ejecución y 2.3 en las siguientes.

Intenté usar -t = "BASURA" para hacer que se saltaran todas las pruebas. el de Linux tardó 1,5 segundos, pero Windows todavía tardó 13, por lo que me parece que no es la ejecución real de las pruebas lo que está tomando el tiempo.

Ambas máquinas usan la última versión de node y jest, y Linux es en realidad una VM que se ejecuta dentro de la de Windows usando Hyper-V, por lo que, en igualdad de condiciones, esperaría que la de Windows sea más rápida.

Solo tengo alrededor de 20 pruebas y acabo de tomar algunos tiempos con broma: observe, tanto en la ejecución inicial como luego presionando enter para volver a ejecutarlas.

En Windows, tomó alrededor de 15 segundos en ambas ocasiones, mientras que para Linux fue de alrededor de 5.3 segundos para la primera ejecución y 2.3 en las siguientes.

Intenté usar -t = "BASURA" para hacer que se saltaran todas las pruebas. el de Linux tardó 1,5 segundos, pero Windows todavía tardó 13, por lo que me parece que no es la ejecución real de las pruebas lo que está tomando el tiempo.

Ambas máquinas usan la última versión de node y jest, y Linux es en realidad una VM que se ejecuta dentro de la de Windows usando Hyper-V, por lo que, en igualdad de condiciones, esperaría que la de Windows sea más rápida.

Si. Y si monta los códigos fuente en la máquina virtual de Linux desde Windows y ejecuta las pruebas, se vuelven tan lentos como en Windows. Esto implica fuertemente que el problema está en la lógica de manejo de archivos de Jest como mencioné anteriormente.

Si. Y si monta los códigos fuente en la máquina virtual de Linux desde Windows y ejecuta las pruebas, se vuelven tan lentos como en Windows. Esto implica fuertemente que el problema está en la lógica de manejo de archivos de Jest como mencioné anteriormente.

Me di cuenta de que mientras se ejecutan las pruebas, la CPU es alta, pero el uso del disco no. Tenía que ver con el bloqueo en los identificadores de archivos, esperaría que tuviera poca CPU (a menos que la broma esté de alguna manera en un bucle cerrado esperando que se liberen los identificadores)

Vi los comentarios de hevans90 sobre los observadores de archivos. No tengo ningún antivirus de terceros instalado o similar instalado, pero deshabilitar la protección en tiempo real incorporada de Windows no hizo ninguna diferencia notable.

Espero que esto sea de alguna ayuda para cualquiera que tenga tiempo para intentar depurarlo.

Así que hoy he confirmado que Windows Defender marca una gran diferencia.
Solía ​​tener un montón de exclusiones, pero cuando recibí mi computadora portátil más nueva y más rápida, no pude entender por qué la broma tardó> 10 minutos en ejecutar un solo archivo.

Entonces recordé las exclusiones.
No puedo decir exactamente qué exclusiones marcan la diferencia, pero logré que el corredor bajara a <15 segundos en lugar de> 10 minutos

Encontré una esencia con exclusiones relevantes (aunque contundente)
https://gist.github.com/darvell/edbc758b11ea4dcd7226b7c9f1821196
También agregué extensiones de archivo .ts .js .spec.ts .spec.js .tsx

No puedo decir exactamente qué exclusiones marcan la diferencia, pero logré que el corredor bajara a <15 segundos en lugar de> 10 minutos

hmm, acabo de intentarlo y no pareció hacer ninguna diferencia para el mío (fíjate, el mío no estaba tomando minutos, así que tal vez estamos experimentando diferentes problemas)

De todos modos, siempre tengo exclusiones. Y, de hecho, IntelliJ Idea sugiere automáticamente colocar el directorio del espacio de trabajo en exclusiones y lo hace por usted si lo permite (debería hacerlo). Entonces, en mi caso, la lentitud no se debe a Windows Defender ni a ningún otro antivirus.

La diferencia de rendimiento es de 5 a 10 veces en comparación con una Mac. La PC es una poderosa máquina de escritorio (léase: mucho más rápida que la macbook). Todo lo demás es rápido como un rayo, solo Jest está sufriendo este problema.

alguna actualización sobre esto? ... estoy experimentando lo mismo, cada prueba tarda mucho en configurarse y se carga, pero después de que se carga la primera, funciona a una velocidad normal ...

También tengo este problema. Un único archivo de prueba con una única prueba de hola mundo y tarda ~ 15 segundos en iniciarse, más otros 12 segundos en ejecutar la prueba.

👋 Veo algunas respuestas que insinúan que están usando mecanografiado con jest; vale la pena investigar esto (si también está usando ts-jest): https://github.com/kulshekhar/ts-jest/issues/ 908 # issuecomment -484043250

El cambio para mí fue pasar de esperar 30 minutos para que la broma (sin caché) comenzara a solo unos segundos.

Tenga en cuenta que configurar el indicador isolatedModules no dará como resultado la verificación de tipos de sus archivos de especificaciones (y la pérdida de algunas funciones): https://github.com/kulshekhar/ts-jest/blob/master/docs/user/ config / isolatedModules.md

Solo estoy publicando esto aquí, ya que podría ser útil para determinar si su problema es broma.

👋 Veo algunas respuestas que insinúan que están usando mecanografiado con jest; vale la pena investigar esto (si también está usando ts-jest): kulshekhar / ts-jest # 908 (comentario)

El cambio para mí fue pasar de esperar 30 minutos para que la broma (sin caché) comenzara a solo unos segundos.

Tenga en cuenta que configurar el indicador isolatedModules no dará como resultado la verificación de tipos de sus archivos de especificaciones (y la pérdida de algunas funciones): https://github.com/kulshekhar/ts-jest/blob/master/docs/user/ config / isolatedModules.md

Solo estoy publicando esto aquí, ya que podría ser útil para determinar si su problema es broma.

JavaScript puro aquí. Tengo este problema, por lo que no está relacionado con TypeScript.

FYI: https://github.com/kulshekhar/ts-jest/pull/1549 estará en la versión alfa de ts-jest (posiblemente hoy). Cualquiera que esté usando ts-jest, por favor ayude a probar la versión alfa y denos algunos comentarios sobre https://github.com/kulshekhar/ts-jest/issues/1115

También tengo este problema. Un único archivo de prueba con una única prueba de hola mundo y tarda ~ 15 segundos en iniciarse, más otros 12 segundos en ejecutar la prueba.

Simplemente ejecuté la misma prueba en una Mac. Se necesitan aproximadamente 1,5 segundos para comenzar, <1 segundo para ejecutar la prueba.

También usando JS, no TS aquí.

JavaScript puro con Jest también aquí. Tengo una potente computadora portátil de cuatro núcleos con procesadores Intel 10gen y todo lo demás es increíblemente rápido, pero [email protected] está tomando 2-3 veces más en Windows que en Linux para ejecutar algunas pruebas básicas.

El mismo problema, unos 60 segundos para que mis pruebas se ejecuten en Windows, y no se muestra la interfaz de usuario durante los primeros 45 segundos más o menos. Ejecuté exactamente el mismo conjunto de pruebas en mi máquina Linux y tardó 8 segundos en completarse.

El comentario anterior de @Cellule aceleró dramáticamente las cosas a unos 15 segundos.

@ryanrapini siguió el consejo de @Cellule (pero pasó por el Windows UI > Virus and Threat Protection > Manage Settings > Add Exclusions ) y vio que algunas pruebas pasaban de 13 segundos a 6, así que básicamente la mitad. ¡Gracias!

¿Alguien quiere contribuir con una sección que mencione Windows Defender (¿o AV en general?) En la página de preguntas frecuentes del sitio web? https://jestjs.io/docs/en/troubleshooting

Puedo confirmar que usar isolatedModules: true con ts-jest hizo una GRAN diferencia en el inicio en frío (~ 10mins => 15sec)
No he probado su mejora en el alfa porque estoy esperando que se solucione el número 9457 antes de actualizar a Jest 25

Hola a todos,

El mismo problema aquí y ninguna solución funciona para mí ...

Ejecuto un código muy simple en el que actualmente tengo algunas pruebas.
Es del "Curso avanzado de reacción" de Wes Bo.
Lo ejecuta en Mac y obtiene una respuesta inmediata de su computadora.

Y para mí:

Suites de prueba: 2 omitidas, 15 aprobadas, 15 de 17 en total
Pruebas: 6 omitidas, 37 aprobadas, 43 en total
Instantáneas: 18 aprobadas, 18 en total
Tiempo: 5.869s
Ejecutó todas las suites de prueba.

isolatedModules: true no cambia nada en mi caso, todavía estoy alrededor de 5-6 segundos.
Y cuando empiezo a probar con cualquier opción, toma de 9 a 10 segundos.

Agregar mi carpeta de desarrollo en Defender Exceptions tampoco hizo nada:

Suites de prueba: 2 omitidas, 15 aprobadas, 15 de 17 en total
Pruebas: 6 omitidas, 37 aprobadas, 43 en total
Instantáneas: 18 aprobadas, 18 en total
Tiempo: 5.563s
Ejecutó todas las suites de prueba.

¿Existe alguna buena opción en Windows?
¿Tengo que ir a wsl2?

Hola a todos,

El mismo problema aquí y ninguna solución funciona para mí ...

Ejecuto un código muy simple en el que actualmente tengo algunas pruebas.
Es del "Curso avanzado de reacción" de Wes Bo.
Lo ejecuta en Mac y obtiene una respuesta inmediata de su computadora.

Y para mí:

Suites de prueba: 2 omitidas, 15 aprobadas, 15 de 17 en total
Pruebas: 6 omitidas, 37 aprobadas, 43 en total
Instantáneas: 18 aprobadas, 18 en total
Tiempo: 5.869s
Ejecutó todas las suites de prueba.

isolatedModules: true no cambia nada en mi caso, todavía estoy alrededor de 5-6 segundos.
Y cuando empiezo a probar con cualquier opción, toma de 9 a 10 segundos.

Agregar mi carpeta de desarrollo en Defender Exceptions tampoco hizo nada:

Suites de prueba: 2 omitidas, 15 aprobadas, 15 de 17 en total
Pruebas: 6 omitidas, 37 aprobadas, 43 en total
Instantáneas: 18 aprobadas, 18 en total
Tiempo: 5.563s
Ejecutó todas las suites de prueba.

¿Existe alguna buena opción en Windows?
¿Tengo que ir a wsl2?

¿Puedes intentar aplicar mi solución y decirme si hace algo? (en realidad, la solución de Cellule, pero lo hice a través del menú en lugar de ejecutar un script)

¿Puedes intentar aplicar mi solución y decirme si hace algo? (en realidad, la solución de Cellule, pero lo hice a través del menú en lugar de ejecutar un script)

Como dije en mi mensaje, ya lo hice :)

Quiero decir, seguí lo que hiciste, a través del menú y todo.

También tengo este problema en Windows. La prueba en sí se ejecuta en <1 segundo, pero la configuración general tarda ~ 15 segundos en ejecutarse. Lo intenté con v24 y v26, en realidad es un poco más lento en v26

No tuve suerte con ninguno de los siguientes (no mejoró el tiempo de ejecución):

• agregando --runInBand
• ajuste maxWorkers
• agregar .ts .js .spec.ts .spec.js .tsx exclusiones a Virus and Threat Protection , como lo sugieren @Cellule y @alessioalex

El mismo problema en Windows aquí con javascript vanilla, así como un nuevo proyecto de mecanografiado. 2 segundos para ejecutar 9 pruebas unitarias que se ejecutan en <10 ms con moca.

¡Esto es Loco!

¡Simplemente instale Jest a nivel mundial y ahora exactamente el mismo proyecto se ejecuta en 0.9s en lugar de 52 (!!!) segundos.
npm remove jest en el proyecto, luego
npm install -g jest

Por supuesto, me gustaría volver a integrar jest como dependencia de desarrollo en el proyecto. ¿Alguna idea de por qué sucede eso?

¡Esto es Loco!

¡Simplemente instale Jest a nivel mundial y ahora exactamente el mismo proyecto se ejecuta en 0.9s en lugar de 52 (!!!) segundos.
npm remove jest en el proyecto, luego
npm install -g jest

Por supuesto, me gustaría volver a integrar jest como dependencia de desarrollo en el proyecto. ¿Alguna idea de por qué sucede eso?

Esto definitivamente me suena a un problema de escáner de virus. Es decir, el directorio de su proyecto está en el alcance del escaneo de virus, lo que ralentiza la broma a un rastreo, pero su directorio npm global no lo está. Sin embargo, esto es solo una suposición.

Acabo de probar lo mismo que @JPustkuchen y el rendimiento va de ~ 10 segundos a <1 segundo.

Excluí la carpeta de mi proyecto de Windows Defender, pero Jest sigue funcionando lento.

No sé si todavía se está trabajando en esto, pero noto que cuando cometo un error tipográfico en el código, las pruebas en el modo de reloj fallan instantáneamente. Lo que me lleva a pensar que en realidad no está forzando un nuevo rastreo de directorio antes de compilar la prueba. Las pruebas muy simples también me están tomando 10 segundos.

Desearía tanto que alguien reconociera al menos que esto es un problema. Como está ahora, mi máquina de escritorio con Windows, que tiene mucha potencia (léase: mucho más que la macbook de mis compañeros de trabajo) es aproximadamente 69 veces más lenta que la macbook al ejecutar pruebas. Esto prácticamente me obliga a no tocar el código de la interfaz, ya que es muy ineficiente para mí trabajar en ellos debido a que las pruebas de Jest se ejecutan tan lentamente. Es posible que tengamos que alejarnos de Jest si esto no se soluciona. Todo lo demás es ultrarrápido, pero las pruebas de Jest son superlentas. El tiempo se dedica a algo más que a ejecutar las pruebas, cuando se ejecuta la lógica de prueba real, éstas van muy rápido.

En una nota más positiva, me gustaría decir que le debo a este error una gran deuda de gratitud. Fue la gota que colmó el vaso que me hizo decidir cambiarme a Linux para mi flujo de trabajo de desarrollo principal y nunca he estado más feliz. No puedo decir que nunca volvería atrás porque a veces tengo que trabajar en proyectos heredados, pero como el núcleo de ASP.NET es multiplataforma, las razones para reiniciar Windows son cada vez menores.

Por favor @ timrobinson33 sigamos en el tema. No hay ninguna razón por la que jest deba ser 68 veces más lento que cualquier otro entorno en Windows, considerando que Node funciona bien en cualquier plataforma. También puedo agregar que no he experimentado este problema con ningún otro corredor de pruebas.

Probé con v26.4.2 en mi repositorio de github de jest de referencia.
https://github.com/nasreddineskandrani/benchmark_jest
versión de nodo en mi computadora: v12.13.0

bastante bien cuando actualizo la prueba simple (ver captura de pantalla)! Para mí, la broma ahora es correcta para una prueba simple.
Si tiene un problema en su trabajo. Debe intentar aislar el problema, ya que por defecto está bien.

@empperi, ¿puedes probar mi repositorio de referencia? ejemplo con la carpeta v26 y dime cuánto tiempo lleva ejecutar esta prueba en tu máquina. si no es 0.166ms o alrededor de él, tiene un problema de su lado.

Probé con v26.4.2 en mi repositorio de github de jest de referencia.
https://github.com/nasreddineskandrani/benchmark_jest
versión de nodo en mi computadora: v12.13.0

bastante bien cuando actualizo la prueba simple (ver captura de pantalla)! Para mí, la broma ahora es correcta para una prueba simple.
Si tiene un problema en su trabajo. Debe intentar aislar el problema, ya que por defecto está bien.

@empperi, ¿puedes probar mi repositorio de referencia? ejemplo con la carpeta v26 y dime cuánto tiempo lleva ejecutar esta prueba en tu máquina. si no es 0.166ms o alrededor de él, tiene un problema de su lado.

Como era de esperar, no hay diferencia en el rendimiento de la configuración de prueba. En realidad, se ejecuta un poco más rápido que en tu computadora. Cambió su configuración de prueba para contener 100 archivos de prueba bajo __tests__ y esos también funcionan bien. Dado que nuestra aplicación usa react-scripts , también agregué eso a su ejemplo para verificar si eso podría causar el problema real pero no una diferencia en el rendimiento.

SIN EMBARGO, entonces traté de ejecutar esas pruebas en WSL2 bash (contra el sistema de archivos NTFS) y boom, el tiempo de ejecución es casi 10 veces superior al de powershell sin procesar. Se espera una velocidad de E / S más lenta en WSL2 contra NTFS, pero considerando lo simple que es esta configuración (solo 100 archivos de prueba con una sola prueba en cada uno), realmente no debería afectar tanto. Como referencia, ejecuté esto en WSL2 bash:

time find . -name "*.js" -print | xargs cat
...(file content prints omitted)...
real    0m0.138s
user    0m0.030s
sys     0m0.000s

Lo que muestra que prácticamente no se necesita tiempo para leer el sistema de archivos de WSL2. Para referencia comando similar en Powershell:

> Measure-Command { ls *.js | % { cat $_ } }

Days              : 0
Hours             : 0
Minutes           : 0
Seconds           : 0
Milliseconds      : 49
Ticks             : 499000
TotalDays         : 5,77546296296296E-07
TotalHours        : 1,38611111111111E-05
TotalMinutes      : 0,000831666666666667
TotalSeconds      : 0,0499
TotalMilliseconds : 49,9

Lo que muestra que la actuación está en el mismo estadio.

Entonces, en base a esto, diría que el problema podría deberse a cómo Jest usa la E / S y eso de alguna manera está afectando el rendimiento drásticamente en WSL2. Cuando se trata del proyecto que me está causando problemas, no es una tarea sencilla no requerir bash debido a problemas en el código y las pruebas (¡no lo hice yo!). Teniendo en cuenta el hecho de que WSL2 está ganando popularidad, diría que este es un problema real que debería estudiarse.

Espero que esto ayude.

:editar:

Solo por curiosidad, ejecuté nuestro conjunto de pruebas con --no-watch para ver si ver el sistema de archivos a través de WSL2 afecta de alguna manera las cosas. La respuesta es no, realmente no afecta tanto.

Ejecutar el punto de referencia en mi máquina con Windows tarda aproximadamente 1,6 segundos. No estoy usando WSL.
Estoy usando el antivirus AVG, pero he agregado excepciones tanto para el repositorio como para el ejecutable del nodo.
Mi disco duro es un SSD.

La versión del nodo es v12.16.1

La actualización de la prueba activa instantáneamente el observador de archivos, pero el tiempo real que lleva ejecutar esa actualización es de alrededor de 1s-2.4s.

Quería probar si el problema es el medio ambiente.

Estaba jugando con este repositorio: https://github.com/kentcdodds/react-testing-library-course/tree/tjs

• Voy por npm test y todas las pruebas comienzan a ejecutarse en modo reloj.
• Presiono 'p' para ingresar un patrón para un archivo y escribo "tdd-02". Recibo más de 3 segundos de tiempo de ejecución.
  

Me sorprendería que Kent C. Dodds tenga un entorno desordenado en su curso pagado, pero si lo tiene, probablemente pueda depurarlo allí:? En sus videos, funciona bien, creo que usa una Mac.

Tengo que señalar algo muy extraño que no puedo reproducir de nuevo: tuve algunas repeticiones de prueba consecutivas que para uno de los archivos (tdd-02 ... js) se ejecutaron durante aproximadamente 0.1s, y para el archivo al lado ( tdd-01 ... js) - alrededor de 3 s. El código es casi el mismo y usa las mismas dependencias. Entonces, copié el código del archivo de ejecución rápida y lo pegué en el de ejecución lenta y viceversa. Los resultados fueron los mismos: el archivo de ejecución lenta siguió siendo lento y el archivo de ejecución rápida permaneció rápido, con los códigos reales intercambiados. Esto se está volviendo loco. Ahora ambos archivos vuelven a funcionar lentamente (3-6 s).

@Glinkis, ¿puedes intentar presionar enter después de la primera ejecución, todavía se muestra en 1.6 segundos? (desencadenar una repetición)

@SimeonRolev echaré un vistazo al ejemplo que publicaste y veré qué tipo de número obtengo con los mismos pasos (patrón ...)
actualizar:
try1: lo probé como tú y obtuve 6 segundos cuando intenté tus pasos -> baja a 3 segundos al volver a ejecutar la misma prueba (presiona enter)
try2: broma mejorada a 26.4 en el repositorio de Kent -> 3 segundos la primera ejecución casi igual para volver a ejecutar
try3: Tomé el archivo index.spec.js de mi repositorio de prueba de referencia. y lo dejé caer en el repositorio de Kent. (eliminando todos los demás archivos de prueba) -> sorpresa 2.8sec (MISMA JEST 26.4.2, MISMA COMPUTADORA, POWERSHELL, NODE_VERSION, etc ... como mi prueba de ayer publicada aquí)

No entiendo este try3 todavía => ~ 3seg al volver a ejecutar en el repositorio de Kent para mi archivo, pero en mi repositorio cae a 0.300s al volver a ejecutar (necesito que alguien lo
editar: Kent debería ser el que verifique esto: P

Al pulsar Intro, la prueba se ejecuta en unos 200 ms.

@nasreddineskandrani ¿Lo intentaste al revés? Quiero decir, ¿copiar las pruebas del repositorio lento al tuyo? Pero no creo que el problema esté en el repositorio que publiqué. Como podemos ver claramente, muchas personas están teniendo el mismo problema, solo estaba publicando un ejemplo reproducible.

@kentcdodds ¿

@SimeonRolev En mi punto de referencia no veo el mismo problema que en el repositorio de Kent. Tienes algo en Kent Repo. que causa esta broma lenta => fuera de ella es más rápida.

Este problema de github está relacionado con el rendimiento de Jest en Windows vs macOS / Linux, ya que no alcanzaron el mismo rendimiento. Supongo que no lo clausuraron. (es mucho mejor ahora que hace 2 años con Jest v23)

Hola, estoy experimentando el mismo problema aquí. Tengo una máquina con Windows y WSL. Copié los archivos de mi proyecto en WSL para probar este comportamiento. Aquí están las ejecuciones de las mismas dos pruebas básicas:
Windows 10 (versión 2004):

WSL 2 (Ubuntu 20.04):

Las pruebas son muy sencillas:

El proyecto se crea con CRA, por lo que no hay ninguna configuración que arruine la configuración, no agregué nada en términos de broma.
Las mismas pruebas se ejecutan increíblemente rápido en moka, casi al instante. Estoy tratando de configurar un entorno de prueba para nuestro proyecto, y realmente me gustaría usar Jest, pero parece que a medida que agrego más y más pruebas, el conjunto de pruebas será cada vez más lento. Cada prueba parece estar agregando 0.8 segundos, lo cual es ridículo, ya que no hacen nada. Algo está interfiriendo con la ejecución de la prueba en Windows, y no sé qué.
El problema era peor, una sola prueba tomaría alrededor de 15 segundos, pero cuando agregué --runInBand y, la situación pareció mejorar un poco, pero creo que todavía no es suficiente, considerando que el modo de reloj moca es instantáneo.

Yarn es la versión 1.22.5, todas las demás dependencias npm (como react y react-scripts) son las más recientes.

Inhabilité el antivirus y el defensor de Windows para ver si tiene algún efecto, pero no lo hace. Además, desactivé la indexación para la carpeta de mi proyecto, pero tampoco fue en vano.

Editar: intenté presionar enter, y las pruebas fueron tan rápidas como en WSL:

Ahora estoy realmente confundido :)

Pero esto todavía parece muy lento, ya que parece que cada prueba toma 0.3 segundos, que es mucho, considerando que no hacen nada. Espero que esta suite se complete en menos de 0,1 segundos.

Edición 2: cuando agregué 100 pruebas a mi conjunto de pruebas, me tomó alrededor de 44 segundos ejecutarlas, incluso si presiono la tecla Intro para ejecutarlas:

Los mismos conjuntos de pruebas tardan entre 9 y 10 segundos en WSL: