Jest: Pruebas de reacción lenta

Hola Tyron. Tuve este problema con más de 20 segundos para un archivo :)
Lo que pasa es que lo configuré para ejecutar 'jest' en el directorio raíz. Y hay MUCHOS subdirectorios que Jest estaba revisando para pruebas. Especificar una ruta para las pruebas redujo este tiempo más de 10 veces ahora. Y también tengo un preprocesador de café. En package.json
"guiones": {
....
"prueba": "ruta de broma / a / módulos / a / prueba"
}

Por cierto, ¿estás preprocesando café o qué? :)

Gracias por responderme @gothy. Estoy usando JS normal con JSX. Solo estoy ejecutando mis pruebas a través del preprocesador JSX como en el ejemplo (https://github.com/facebook/jest/tree/master/examples/react). El ejemplo también tarda entre 2,5 y 3 segundos en ejecutarse. El ejemplo de jQuery tarda menos de un segundo. ¿El preprocesador JSX está diseñado para tomar tanto tiempo al procesar sus archivos JSX?

Prueba de reacción

Prueba de jQuery

Ah, no lo usé para JSX. No puedo decir nada sobre este procesador. Quizás sea realmente lento. Encontré mi problema con los directorios en un proyecto real con un montón de cosas antiguas :)

Experimenté un problema similar con el preprocesador de Coffeescript. Creo que el problema aquí es que el preprocesador también intenta procesar sus dependencias. Si necesita muchas cosas, se ralentiza.

Definitivamente también experimento pruebas lentas con broma :(

Estoy experimentando lo mismo. No creo que tenga que ver con el preprocesamiento (el procesamiento JSX en este pequeño archivo es rápido). Comenté todo el código en la prueba de ejemplo, excepto una de las siguientes declaraciones require y la prueba aún toma 4 segundos. Tan pronto como los comento, la prueba tarda 0,1 s. Investigué un poco y parece que HasteModuleLoader tiene que procesar 490 paquetes requeridos (_shouldMock ()) y no burlarse de ellos cuando requiera reaccionar / complementos.

var React = require('react/addons');

o

var CheckboxWithLabel = require('../CheckboxWithLabel.js');

Eliminé los siguientes var React = require('react/addons'); y aún ejecuté los archivos a través del preprocesador. Obtuve tal vez una mejora de 0.2 segundos. Si eliminé el preprocesador, obtengo los siguientes resultados:

Con el preprocesador JSX

Sin el preprocesador JSX

Prefiero Mocha sobre Jasmine y decidí configurar un archivo gulp que compilaría el componente de reacción y luego lo ejecutaría a través del conjunto de pruebas de mocha (fragmento a continuación).

function buildScript(file, watch) {
  var bundler = browserify(file);
  var stream;
  bundler.transform(reactify);
  stream = bundler.bundle();
  return stream.on('error', handleErrors)
  .pipe(source(file))
  .pipe(gulp.dest(buildDir + '/'))
  .pipe(mocha({ reporter: 'list' }));
}

Todavía tiene que preprocesar el archivo JSX usando reactify, pero elimina el mensaje de advertencia para pruebas lentas. Por lo tanto, el tiempo de ejecución aún toma menos de 2 segundos, pero la prueba real es de aproximadamente 32 ms. Aún estoy decidiendo si vale la pena usar JSX.

Oh, tienes razón. Probé el ejemplo de reacción de broma sin usar JSX y pasó de cerca de 4 segundos a 0,75 segundos. Realmente me hace pensar si vale la pena usar JSX. En un proyecto grande, se ralentizará bastante rápido a menos que tenga muchos paquetes diferentes. Me pregunto si el preprocesador se ejecuta en todos los requisitos 490 y no solo en ese archivo. No hay forma de que deba tomar 3 segundos para ese componente simple.

De cualquier manera, realmente necesito que mis pruebas sean rápidas para mi flujo de trabajo. Todavía necesito averiguar cómo ejecutar al menos una sola suite. En jazmín, podría usar "ddescribe" o "iit" en lugar de "describe" y "eso" para ejecutar una única prueba o suite. Jest es TAN agradable, solo necesito un flujo de trabajo rápido ahora.

var React = require('react');

var CheckboxWithLabel = React.createClass({displayName: 'CheckboxWithLabel',
    getInitialState: function() {
        return { isChecked: false };
    },
    onChange: function() {
        this.setState({isChecked: !this.state.isChecked});
    },
    render: function() {
        return (
            React.DOM.label(null,
                React.DOM.input(
                    {type:"checkbox",
                        checked:this.state.isChecked,
                        onChange:this.onChange}
                ),
                this.state.isChecked ? this.props.labelOn : this.props.labelOff
            )
            );
    }
});

module.exports = CheckboxWithLabel; 

@jeffchan tenía razón. Todo el código requerido se ejecuta a través del preprocesador, no solo los archivos JSX.

Parece que la solución más rápida será usar gulp, watchify y reaccionar para procesar solo los archivos JSX modificados mientras trabaja. Entonces podremos especificar solo las pruebas que quiero ejecutar también. De esta manera, los archivos JSX solo se procesan una vez y yo tengo control sobre qué pruebas se ejecutan. Algo como esto sería realmente bueno para un flujo de trabajo de prueba.

gulp jest --tests "Checkbox*,*Form*"

Watchify luego observará los cambios de los que dependen estas pruebas, y luego solo procesará los cambios y luego solo ejecutará las pruebas con las que estoy trabajando.

@iamrandys Estoy 100% de acuerdo contigo. Jest y React son increíbles, pero la compilación de JSX en JS es un gran obstáculo. ¿Solo tiene curiosidad por saber cómo resolverá Gulp el problema de que sus archivos requeridos (no JSX) se ejecuten a través del preprocesador JSX? ¿Está sugiriendo algo como lo siguiente: http://blog.avisi.nl/2014/04/25/how-to-keep-a-fast-build-with-browserify-and-reactjs/ ?

Sí, estoy pensando en algún tipo de capa de almacenamiento en caché con el complemento gulp en
trabajando en

El 11 de agosto de 2014 a las 08:35, Tyrone Avnit [email protected] escribió:

@iamrandys https://github.com/iamrandys Estoy 100% de acuerdo contigo. Broma y
React es increíble, pero la compilación de JSX en JS es un gran obstáculo. Solo
curioso cómo Gulp resolverá el problema de tener los archivos requeridos (no
JSX) se está ejecutando a través del preprocesador JSX? Estas sugiriendo algo
como el siguiente? -
http://blog.avisi.nl/2014/04/25/how-to-keep-a-fast-build-with-browserify-and-reactjs/
?

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/facebook/jest/issues/116#issuecomment -51749798.

Exactamente, usar gulp y watchify es increíblemente rápido para reaccionar. Lanzar en
gulp-livereload para actualizar su navegador después de cada cambio y tiene una
increíble entorno de desarrollo. Haces cualquier cambio, ahorras y casi
vea instantáneamente los cambios en todos sus navegadores abiertos y todos los dispositivos. Ahora yo
solo necesito lo mismo para mi TDD.

Se trata de esto, pero usa reactify en lugar de hbsfy.
https://gist.github.com/benhowdle89/9533185

El lunes 11 de agosto de 2014 a las 2:35 a. M., Tyrone Avnit [email protected]
escribió:

@iamrandys https://github.com/iamrandys Estoy 100% de acuerdo contigo. Broma y
React es increíble, pero la compilación de JSX en JS es un gran obstáculo. Solo
curioso cómo Gulp resolverá el problema de tener los archivos requeridos (no
JSX) se está ejecutando a través del preprocesador JSX? Estas sugiriendo algo
como el siguiente? -
http://blog.avisi.nl/2014/04/25/how-to-keep-a-fast-build-with-browserify-and-reactjs/
?

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/facebook/jest/issues/116#issuecomment -51749798.

Gracias @iamrandys. Se desarrolló una placa de caldera de componentes de reacción rápida que utiliza Mocha y Chai (el jazmín se puede sustituir fácilmente). Las pruebas son extremadamente rápidas y obtienes el beneficio adicional de Livereload. Úselo como desee.

De cualquier manera, realmente necesito que mis pruebas sean rápidas para mi flujo de trabajo. Todavía necesito averiguar cómo ejecutar al menos una sola suite. En jazmín, podría usar "ddescribe" o "iit" en lugar de "describe" y "eso" para ejecutar una única prueba o suite. Jest es TAN agradable, solo necesito un flujo de trabajo rápido ahora.

Definitivamente puedes escribir it.only y creo que también puedes hacer describe.only .

Karma hace exactamente lo que quieres y todo lo que tienes que hacer es agregar un
karma.conf en su proyecto. No me di cuenta de que el karma apoyaba reacciona
y browserify. Ahora puede probar en todos sus navegadores al mismo tiempo.
Creé un PR para su proyecto estándar.

https://github.com/iamrandys/react-component-boilerplate/tree/karma

Simplemente ejecute 'npm test' y karma iniciará sus navegadores y observará
cambios.

El martes 12 de agosto de 2014 a las 10:35 a. M., Tyrone Avnit [email protected]
escribió:

Gracias @iamrandys https://github.com/iamrandys. Desarrolló un rápido
react-componente-boilerplate
https://github.com/TYRONEMICHAEL/react-component-boilerplate que utiliza
Mocha y Chai (el jazmín se puede sustituir fácilmente). Las pruebas son extremadamente
rápido y obtiene el beneficio adicional de Livereload. Úselo como desee.

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/facebook/jest/issues/116#issuecomment -51931532.

Utilice el siguiente preprocessor.js para evitar la transformación de archivos JSX que no son JSX. Tal como está, solo procesa archivos .jsx que contienen el prefijo /** @jsx . Si desea transformar archivos JSX .js , simplemente elimine la primera parte de la condición if antes de || (para que solo quede la condición src.slice ... ).

// from http://facebook.github.io/jest/docs/tutorial-react.html
var ReactTools = require('react-tools');
var MAGIC = "/** @jsx";
module.exports = {
  process: function(src, file) {
    if (!/\.jsx$/.test(file) || src.slice(0, MAGIC.length) != MAGIC) return src;
    return ReactTools.transform(src);
  }
};

Sin embargo, sigue siendo un poco lento.

Fragmento interesante @sqs. Corrígeme si me equivoco, pero ¿no tendría que revisar cada archivo y comprobar si es necesario convertirlo? He tenido mucho éxito con lo siguiente: react-component-boilerplate . En realidad, las pruebas se ejecutan con bastante rapidez.

Muy agradable. Esto redujo el tiempo de 9,3 a 4,7 segundos. Esto es para una sola prueba. Todavía tendré que quedarme con Karma donde es mucho más rápido (100 pruebas toman menos de un segundo). Además, Karma observará los cambios mientras trabajas y probará tu código en varios navegadores, pero me encanta la burla automática de Jest. Crear espías manualmente usando rewireify es un trabajo extra, pero tienes el control total.

Sí, puede que no lo esté entendiendo, pero eso es lo que quise decir acerca de eliminar el cheque para .jsx si tiene archivos .js con jsx y desea detectar según el encabezado pragma.

Enviado desde mi iPhone

El 28 de agosto de 2014, a las 23:45, Tyrone Avnit [email protected] escribió:

Fragmento interesante @sqs. Corrígeme si me equivoco, pero ¿no tendría que revisar cada archivo y comprobar si es necesario convertirlo? He tenido mucho éxito con lo siguiente: react-component-boilerplate. En realidad, las pruebas se ejecutan con bastante rapidez.

-
Responda a este correo electrónico directamente o véalo en GitHub.

¡Hola! Estoy trabajando en --watch por broma y, en general, trato de hacer que esto sea más rápido. Informaré pronto.

la primera ejecución para mí toma alrededor de 5 segundos (solo tengo una prueba, recién estoy comenzando). Después de eso, cada ejecución adicional dura aproximadamente 1,2-1,5 segundos.

Parece que se gasta una cantidad decente de ese tiempo cargando el caché de prisa (que para mi proyecto ya es un archivo de 4 megas).

Estoy deseando que llegue el trabajo --watch , pero también me pregunto qué está pasando que requiere 1.2 segundos de tiempo de carga para ejecutar una prueba. No sé nada sobre lo que está haciendo la prisa y por qué Jest lo está usando, así que no tengo ni idea.

Haste admite un tipo de formato de módulo CommonJS donde los nombres de los módulos son de nivel superior en lugar de relativos. Eso significa que necesitamos conocer los módulos (y dependencias) antes de ejecutar el programa, de lo contrario sería increíblemente ineficiente atravesar el sistema de archivos para buscar un módulo en cada require . Sin embargo, nos damos cuenta de que la mayoría de las personas están usando el formato de módulo relativo (a la node.js) y queremos eliminar la dependencia implícita de Haste (a menos que se proporcione una opción) y esto debería hacerlo más rápido.

@amasad eso suena genial. Probé intern.js y ejecuta una prueba unitaria regular desde la línea cmd para terminar en unos pocos ms. ¿Crees que la broma podría llegar tan rápido? ¿Y ha considerado extraer la parte de autoempaquetado para que se pueda utilizar en otros marcos como jazmín o moca?

He descubierto que los archivos requeridos (especialmente 'react / addons' y el módulo que se está probando) una vez bajo la devolución de llamada descrita, en lugar de repetidamente en las devoluciones de llamada beforeEach o it hacen una gran diferencia.

Obviamente, estoy usando coffee-script y no jsx, pero esto ahorra tanto el trabajo del preprocesador como el trabajo de broma para simular automáticamente las llamadas require .

__tests__/login_fields.coffee (3.013s) (¡ay!)

describe 'Login Fields', -> 
 beforeEach ->
    {TestUtils} = require('react/addons').addons
    LoginFields = require '../login_fields'
    ...
  it 'should have left animation states defined', ->
    {TestUtils} = require('react/addons').addons
    ...
  it 'should have a translateX value equal to enterStateStart.left', ->
    {TestUtils} = require('react/addons').addons
    ...
  it 'should call handleLogin on button click or enter press with the entered username and password', ->
    {TestUtils} = require('react/addons').addons
    ...
  it 'should call updateFields on all change events', ->
    {TestUtils} = require('react/addons').addons
    ...

pero, se vuelve mucho más rápido con ...
__tests__/login_fields.coffee (0.604s) (nada mal)

describe 'Login Fields', ->
  {TestUtils} = require('react/addons').addons
  LoginFields = require '../login_fields'
  # require other repeatedly needed modules here as well

  beforeEach ->
    # now you can use TestUtils to renderIntoDocument LoginFields here

  it 'should have left animation states defined', ->
    # and use TestUtils here
  ...

Mis pruebas duran 14 segundos, incluso después de usar todas las optimizaciones recomendadas hasta ahora. Incluso con 16 GB de RAM y SSD. Jest es totalmente inutilizable en su estado actual. Lo siento, cambiando a Karma.

He encontrado un gran éxito con karma, mocha, chai, sinon, rewireify y aliasify. Más de 300 pruebas se ejecutan en 1/2 segundo. ¡Lo mejor de todo React es INCREÍBLE! Al equipo le ENCANTA y ha estado desarrollando algunas cosas realmente buenas con él. Es tan limpio y fácil de mantener. Gran diferencia con cualquier cosa que hayamos usado.

Me encontré con esto yo mismo. Las pruebas se ejecutan _REALMENTE_ lentas. El problema con las pruebas lentas es que los desarrolladores las desactivan o solo las ejecutan parte del tiempo. ¿Alguna idea que está causando esto? ¿Cómo puedo ayudar?

Tuve este problema exacto: las pruebas tardaron unos 17 segundos en ejecutarse inicialmente y luego 4 segundos después del almacenamiento en caché. Resulta que mi directorio de compilación y los módulos externos no se excluyeron correctamente. Establecer la opción de configuración testPathDirs para que apunte al directorio de origen redujo los tiempos de ejecución a 0,5 segundos.

Esto funcionó para mí usando React v0.12 +:

var ReactTools = require('react-tools');


module.exports = {
  process: function(src, file) {
    if(!file.match(/\.react\.js$/)) return src;

    return ReactTools.transform(src);
  }
};

También comencé a usar Jest, solo probando módulos regulares de JavaScript (sin JSX / React) y Jest es muy lento. Me encanta la idea de las pruebas en línea y las burlas integradas, pero es tan dolorosamente lento que me hace extrañar a Mocha. No estoy seguro de cuál es el culpable ... no está buscando en el árbol de directorios lo que está causando la velocidad lenta. Si especifico el archivo directamente, sigue siendo muy lento.

¿Alguna idea sobre al menos la causa de la lentitud? (No estoy usando JSX / CoffeeScript; la simulación automática está desactivada)

El ejemplo original nunca funcionó para mí, ya que el primer argumento siempre resultó verdadero.

var ReactTools = require('react-tools');
var MAGIC = "/** <strong i="6">@jsx</strong> ";
module.exports = {
  process: function(src, file) {
    if (src.slice(0, MAGIC.length) != MAGIC) return src;
    return ReactTools.transform(src);
  }
};

@culshaw @haihappen gracias por las buenas soluciones, acorte las pruebas de 10s + a 2+. estas soluciones me hicieron pensar que tal vez deberíamos usar la extensión _.jsx / _. react.js para nuestros archivos de reacción, creo que también podría ayudar al usar reactify.

Para ser honesto, al pasar por Grunt, todavía estaba obteniendo tiempos de + 20, obtuve
Reacciona trabajando con Karma y el tiempo total es de aproximadamente +4/5 segundos.

Aunque todo dentro de una máquina virtual

Solo para informar sobre esto. Hemos estado probando reaccionar con Karma / Mocha y estamos cerca de 700 pruebas y se tarda unos 4 segundos en ejecutar todas las pruebas. Tenemos que manejar las burlas, pero vale la pena. React ha sido INCREÍBLE. Impecable y refrescantemente estable. ¡Cambiador de juego! Nuestro equipo no pudo obtener imágenes usando nada más.

Nunca conseguí que Jest fuera rápido. Estoy usando moca. Si Jest fue rápido, yo
lo habría usado en su lugar.

El jueves 5 de febrero de 2015 a las 12:17 p.m., Gil Birman [email protected]
escribió:

@iamrandys https://github.com/iamrandys ¿te importaría explicar en
más detalles de cómo te las arreglaste para hacer una broma tan rápido?

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/facebook/jest/issues/116#issuecomment -73097182.

Gracias @iamrandys había borrado mi "¿cómo conseguiste bromear para ser rápido?" pregunta después de darme cuenta de que había leído mal tu publicación (pero respondiste al mismo tiempo) ... de todos modos, es una pena, supongo que la broma aún debería considerarse no tan lista para el uso de producción.

las soluciones / cambios de @haihappen y @darcyadams me ayudaron a

Tengo el mismo problema: obtuve solo 3 pruebas en un proyecto pequeño y demoran 3 segundos.

¿Mejorar el rendimiento está cerca de la hoja de ruta del proyecto?

Por cierto: Encontré una forma (bastante pirateada) de volver a ejecutar las pruebas unitarias solo para los archivos que han cambiado. Esto los vuelve bastante rápidos, ya que generalmente solo hay una prueba para ejecutar. Lo puse aquí: https://gist.github.com/mik01aj/fefb7718331e5454b9d1

Strange Jest no se mencionó en React.js 2015 conf.

testPathDirs parece ser el culpable. Especifique así en package.json:

  "jest": {
    "unmockedModulePathPatterns": [
      "./node_modules"
    ],
    "scriptPreprocessor": "./preprocessor.js",
    "testDirectoryName": "tests",
    "testPathDirs": ["tests"]
  }

@adjavaherian tenga cuidado con eso si está usando la burla automática: https://github.com/facebook/jest/issues/176

De hecho, espere que la burla automática se rompa de manera sutil y frustrante si su testPathDirs no cubre sus dependencias.

Estas preocupaciones me hacen pensar que podríamos estar haciendo algo mal con nuestra configuración de prueba. Podría estar equivocado aquí, pero hasta donde yo sé, todos estamos usando cosas como: var component = React.createFactory(require("component/path")) junto con otros módulos requeridos antes de cada prueba. Seguramente esto no debe ser necesario para todas las pruebas. Me refiero a que una fábrica debería producir un componente nuevo cada vez. Si muevo el requisito fuera del anterior , la velocidad de prueba de

No estoy seguro si esto ayuda. ¿Pensamientos?

Sería bueno si el tiempo de preprocesamiento se dejara fuera del tiempo de ejecución de la prueba informado. Es un poco injusto verlo en rojo cuando la mayor parte de ese trabajo proviene de un paso de transformación.

Hola tios,

Estoy teniendo el mismo problema. Incluso tengo algunos casos de prueba que tardan alrededor de 1 minuto en ejecutarse :(

No sé por dónde empezar a perfilar el problema de rendimiento, ¿alguna pista?

ACTUALIZAR

Solucioné este problema que solo aparecía en mi entorno de VM (cf: http://stackoverflow.com/a/13703132). Ahora las pruebas siguen siendo más lentas de lo que esperaba, pero mucho más rápidas que antes de la solución vagabunda (60 segundos -> 6 segundos para mi traje de prueba)

Si la velocidad sigue siendo un problema, sugiero pasar a Mocha. Hemos tenido mucho éxito con esta bifurcación, que explica cómo configurar pruebas para implementaciones de React simples a complejas. https://github.com/adjavaherian/mocha-react Regularmente realizamos más de 100 pruebas en aproximadamente 3 segundos.

Estoy de acuerdo en que Mocha es el camino a seguir. Hasta casi 900 pruebas y tarda unos 4 segundos.

El 23 de abril de 2015, a las 4:53 p.m., Amir Djavaherian [email protected] escribió:

Si la velocidad sigue siendo un problema, sugiero pasar a Mocha. Hemos tenido mucho éxito con esta bifurcación, que explica cómo configurar pruebas para implementaciones de React simples a complejas. https://github.com/adjavaherian/mocha-react Regularmente realizamos más de 100 pruebas en aproximadamente 3 segundos.

-
Responda a este correo electrónico directamente o véalo en GitHub.

La misma experiencia, acabo de configurar Jest con solo una prueba (usando JSX) y toma alrededor de 3 segundos, esto es mucho.

@iamrandys, ¿te importaría mostrar un ejemplo de tu configuración? Parece la combinación perfecta.

@amasad ¿Existe una opción con Jest para crear un caché para archivos compilados similar a lo que permite babel-loader en la opción cacheDirectory? - https://github.com/babel/babel-loader#options

Lo que hace que Jest sea lento para mí no es la compilación, sino el inicio de los procesos del grupo de trabajadores. Todas mis pruebas pasan en menos de 0.05 segundos, excepto las primeras, que toman alrededor de 4 segundos.
https://github.com/jeffmo/node-worker-pool
https://github.com/facebook/jest/blob/master/src/TestRunner.js#L376

@songawee ¿ No lo hace, pero quiere enviar un PR para tenerlo como una opción? No creo que debamos tenerlo activado de forma predeterminada porque a veces es imposible saber cuándo romper el caché. Por ejemplo, si cambia las opciones del compilador, la caché debería reiniciarse. Otra opción es tener una opción de reinicio de caché además del almacenamiento en caché.

@doodzik, ¿estás seguro de que es el grupo de trabajadores y no el node-haste indica y lee los módulos?

@amasad Lo que hice fue medir el tiempo que jest para completarse.
Y el node-worker-pool fue la última instancia en la que las pruebas fueron lentas.
Podría ser que mis hallazgos sean solo el síntoma y no la raíz del problema.
Pero no había tenido tiempo de analizarlo adecuadamente.

Mis pruebas actualmente se ven así:

Mis pruebas de reacción son lentas (las de la carpeta de ejemplos). Estoy hablando de las pruebas de no reacción.

+1

Aquí igual. Las pruebas son muy, muy lentas: decepcionadas:

Pensé que era solo yo quien enfrentaba el problema. Es la primera vez que uso Jest y tampoco obtengo un resultado rápido. ¿Se pregunta cómo Facebook hace la prueba con Jest?

Mi pregunta sobre las mejoras de Jest a los chicos de React en la sesión de preguntas y respuestas de la conferencia React Europe: https://youtu.be/CRJZBZ_-6hQ?t=363

Cambiado a Mocha + Sinon. Nunca he sido más feliz.

El 31 de agosto de 2015 a las 17:45, Alan Rubin [email protected] escribió:

Mi pregunta sobre Jest a los chicos de React en la conferencia de preguntas y respuestas de React Europe
sesión - https://youtu.be/CRJZBZ_-6hQ?t=363

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/facebook/jest/issues/116#issuecomment -136394910.

Tengo el mismo problema. Las pruebas de broma toman mucho tiempo y el tiempo de ejecución varía. No importaba si ejecutarlos en paralelo o en un solo proceso (--runInBand). Parece no ser una disputa de recursos entre los procesos de trabajo.

Creé algunos volcados de CPU con el generador de perfiles v8 (https://github.com/node-inspector/v8-profiler) y descubrí que la mayor parte del tiempo parece dedicarse a burlar módulos. Es decir, el 25% del tiempo de ejecución de mi prueba unitaria se gasta en jest-cli / src / lib / utils.js # runContentWithLocalBindings.

alguna actualización de rendimiento? acabo de captar broma con es6 y babel-jest, pero ejecutando 2 pruebas simples en> 10 segundos :-(
Probé muchas ideas de este hilo para acelerar, pero nada funcionó ...

Nos centraremos en esto pronto. Estamos un poco abrumados con el trabajo en broma en este momento, pero estamos comprometidos a hacerlo más asombroso.

¿Hay alguna tarea en la que la comunidad pueda ayudar?

+1

La mayor ayuda en este momento sería mejorar la documentación, el sitio web y resolver los problemas y ayudar a las personas en código abierto.

Una cosa que hemos hecho para acelerar nuestras pruebas JEST en el proceso de construcción fue reemplazar nuestra máquina de un solo núcleo por una de múltiples núcleos. De forma predeterminada, broma genera tantos trabajadores como subprocesos de hardware estén disponibles. Si esto no está disponible para usted, puede jugar manualmente con '-w' (maxWorkers). Puede obtener una aceleración también en un solo núcleo.

En última instancia, descubrimos que la simulación de módulos es muy costosa (consulte mi comentario anterior) y causa la mayor parte del tiempo de ejecución.

Bromear con es6 para mí es completamente inutilizable. se necesitan más de 10 segundos para iniciarse, y luego se necesitan 2 segundos para ejecutar la única prueba que tengo en este momento. Esperaba mucho más, volviendo al karma :(

Actualmente estamos trabajando para reemplazar node-haste con un nuevo módulo de resolución, que debería solucionar este problema.

Hola a todos. ¿Hay alguna novedad sobre este tema?

Hola, ¿Jest es adecuado para pruebas que no sean de React? Me gustaría tener un estándar común para las aplicaciones de reacción y no reacción en nuestro equipo.

Jest es un corredor de pruebas universal y no es necesario que uses React. :) ¡Eche un vistazo a uno de los ejemplos!

Hola a todos, información muy interesante aquí. También estoy experimentando problemas con las pruebas que se ejecutan lentamente. Actualmente tengo 13 pruebas que tardan ~ 15 segundos en ejecutarse.

Descubrí que agregar "testPathDirs": ["<rootDir>/path/to/tests/"] a nuestro archivo packages.json ayudó a mejorar considerablemente el tiempo de inicio.

@cpojer ¿Tiene alguna actualización para nosotros sobre el nuevo y mejorado solucionador de módulos? Realmente espero que esta sea la clave para que las pruebas se ejecuten mucho más rápido

Este trabajo está sucediendo en el n. ° 599.

Gracias @cpojer 😀
Espero ver el Haste2 terminado.

Las mismas pruebas que usan moca se ejecutan en 44 ms para mí, donde la broma tomó 6 segundos completos.

Me tomó unos 15 minutos cambiar mis 6 archivos de prueba iniciales usando jest por usar Mocha , jsdom y sinon .

Buenas noticias a todos, estoy fusionando el # 599 hoy y debería acabar con el lento inicio, finalmente.

Ok, esto finalmente debería arreglarse en Jest 0.9. Lamento que esto haya tomado tanto tiempo, pero hubo algunas payasadas en Jest :)

Consulte https://github.com/facebook/react/pull/6052 sobre cómo se aceleraron las pruebas de React. Si desea probar esta mejora, consulte los comentarios en el n. ° 599. Actualmente está etiquetado como jest-cli@next hasta para ver si hay algún error que pueda encontrar la gente en el código abierto. Cerraré este problema como resuelto.

npm install jest-cli@next si desea ejecutar esta nueva versión (en lugar de jest@next @cpojer)

oh sí, siempre cometo este error :) Edité mi comentario original.

@cpojer después de actualizar usando npm install jest-cli@next Tengo problemas para especificar dontMock . Con lo que quiero decir, antes de la actualización (usando [email protected]) esta línea funciona correctamente:

jest.dontMock('../../../../fixtures');

luego, después de la actualización a 0.9.0, la misma llamada hace que el módulo sea simulado

@steinbachr que probablemente debería ir a un tema aparte. Sería genial si pudieras proporcionar una reproducción, ¡no he visto este problema en FB!

gracias @cpojer , problema creado aquí