Jest: Tests de réaction lente

Salut Tyron. J'ai eu ce problème avec plus de 20 secondes pour un fichier :)
Le truc, c'est que j'ai configuré pour simplement exécuter 'jest' dans le répertoire racine. Et il y a BEAUCOUP de sous-répertoires que Jest vérifiait pour les tests. La spécification d'un chemin pour les tests a réduit ce temps plus de 10 fois maintenant. Et j'ai aussi un préprocesseur de café. Dans package.json
"scripts": {
....
"test": "chemin de plaisanterie/vers/modules/vers/test"
}

BTW, prétraitez-vous le café ou quoi ? :)

Merci de m'avoir répondu @gothy. J'utilise JS standard avec JSX. J'exécute simplement mes tests via le préprocesseur JSX comme dans l'exemple (https://github.com/facebook/jest/tree/master/examples/react). L'exemple prend également environ 2,5 à 3 secondes pour s'exécuter. L'exemple jQuery prend moins d'une seconde. Le préprocesseur JSX est-il censé prendre autant de temps lors du traitement de vos fichiers JSX ?

Test de réaction

Test jQuery

Ah, je ne l'ai pas utilisé pour JSX. Je ne peux rien dire sur ce processeur. Peut-être que c'est en fait lent. J'ai trouvé mon problème avec les répertoires sur un vrai projet avec plein de vieux trucs :)

J'ai rencontré un problème similaire avec le préprocesseur Coffeescript. Je pense que le problème ici est que le préprocesseur essaie également de traiter vos dépendances. Si vous avez besoin de beaucoup de choses, cela ralentit.

J'expérimente certainement aussi des tests lents avec jest :(

Je vis la même chose. Je ne pense pas que cela ait à voir avec le prétraitement (le traitement JSX sur ce petit fichier est rapide). J'ai commenté tout le code dans l'exemple de test à l'exception de l'une des instructions require suivantes et le test prend encore 4 secondes. Dès que je les commente, le test prend 0,1 s. J'ai creusé un peu et il semble que le HasteModuleLoader doive traiter 490 packages requis (_shouldMock()) et ne pas se moquer d'eux lorsque vous avez besoin de la réaction/des addons.

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

ou

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

J'ai supprimé les var React = require('react/addons'); et j'ai toujours exécuté les fichiers via le préprocesseur. J'ai peut-être 0,2 seconde d'amélioration. Si j'ai supprimé le préprocesseur, j'obtiens les résultats suivants :

Avec le préprocesseur JSX

Sans le préprocesseur JSX

Je préfère Mocha à Jasmine et j'ai décidé de configurer un fichier gulp qui construirait le composant de réaction, puis de l'exécuter via la suite de tests mocha (extrait ci-dessous).

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' }));
}

Il doit encore prétraiter le fichier JSX à l'aide de reactify, mais supprime le message d'avertissement pour les tests lents. Ainsi, le temps d'exécution prend encore un peu moins de 2 secondes, mais le test réel est d'environ 32 ms. Je décide toujours si l'utilisation de JSX en vaut la peine.

Ah tu as raison. J'ai testé l'exemple de plaisanterie sans utiliser JSX et il est passé de près de 4 secondes à 0,75 seconde. Cela me fait vraiment penser si cela vaut la peine d'utiliser JSX. Sur un gros projet, ça va ralentir assez rapidement à moins que j'aie beaucoup de packages différents. Je me demande si le préprocesseur est exécuté sur tous les 490 requis et pas seulement sur ce seul fichier. Il est impossible que cela prenne 3 secondes pour ce simple composant.

Quoi qu'il en soit, j'ai vraiment vraiment besoin que mes tests soient rapides pour mon flux de travail. J'ai encore besoin de comprendre comment faire fonctionner au moins une seule suite. Dans jasmine, je pourrais utiliser "ddescribe" ou "iit" au lieu de "describe" et "it" pour exécuter un seul test ou une seule suite. Jest est TELLEMENT gentil, j'ai juste besoin d'un flux de travail rapide maintenant.

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 avait raison. Tout le code requis est exécuté via le préprocesseur, pas seulement les fichiers JSX.

Il semble que la solution la plus rapide consiste à utiliser gulp, watchify et réagir pour ne traiter que les fichiers JSX modifiés pendant que vous travaillez. Nous pourrons alors spécifier uniquement les tests que je souhaite également exécuter. De cette façon, les fichiers JSX ne sont traités qu'une seule fois et je contrôle les tests à exécuter. Quelque chose comme ça serait vraiment bien pour un workflow de test.

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

Watchify surveillera ensuite les modifications dont ces tests dépendent, puis ne traitera que les modifications, puis n'exécutera que les tests avec lesquels je travaille.

@iamrandys Je suis à 100% d'accord avec toi. Jest et React sont géniaux, mais la compilation de JSX en JS est un gros obstacle. Juste curieux de savoir comment Gulp résoudra le problème de l'exécution de vos fichiers requis (non JSX) via le préprocesseur JSX ? Suggérez-vous quelque chose comme ce qui suit - http://blog.avisi.nl/2014/04/25/how-to-keep-a-fast-build-with-browserify-and-reactjs/ ?

Oui, je pense à une sorte de couche de mise en cache avec le plugin gulp dans
travaille sur

Le 11 août 2014 08:35, Tyrone Avnit [email protected] a écrit :

@iamrandys https://github.com/iamrandys Je suis à 100% d'accord avec toi. Blague et
React est génial, mais la compilation de JSX en JS est un gros obstacle. Seulement
curieux de savoir comment Gulp résoudra le problème d'avoir vos fichiers requis (Non
JSX) exécuté via le préprocesseur JSX ? Suggérez-vous quelque chose
comme le suivant ? -
http://blog.avisi.nl/2014/04/25/how-to-keep-a-fast-build-with-browserify-and-reactjs/
?

-
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/facebook/jest/issues/116#issuecomment-51749798 .

Exactement, utiliser gulp et watchify est incroyablement rapide avec réagir. Jeter dans
gulp-livereload pour rafraîchir votre navigateur après chaque changement et vous avez un
environnement de développement incroyable. Vous effectuez n'importe quel changement, enregistrez et vous avez presque
voir instantanément les changements dans tous vos navigateurs ouverts et tous les appareils. Maintenant je
juste besoin de la même chose pour mon TDD.

C'est à peu près comme ça, mais utilisez reactify au lieu de hbsfy.
https://gist.github.com/benhowdle89/9533185

Le lundi 11 août 2014 à 02h35, Tyrone Avnit [email protected]
a écrit:

@iamrandys https://github.com/iamrandys Je suis à 100% d'accord avec toi. Blague et
React est génial, mais la compilation de JSX en JS est un gros obstacle. Seulement
curieux de savoir comment Gulp résoudra le problème d'avoir vos fichiers requis (Non
JSX) exécuté via le préprocesseur JSX ? Suggérez-vous quelque chose
comme le suivant ? -
http://blog.avisi.nl/2014/04/25/how-to-keep-a-fast-build-with-browserify-and-reactjs/
?

-
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/facebook/jest/issues/116#issuecomment-51749798 .

Merci @iamrandys. Développement d'une plaque chauffante à composants à réaction rapide qui utilise du moka et du chai (le jasmin peut être facilement remplacé). Les tests sont extrêmement rapides et vous bénéficiez en plus de Livereload. Utilisez comme vous le souhaitez.

Quoi qu'il en soit, j'ai vraiment vraiment besoin que mes tests soient rapides pour mon flux de travail. J'ai encore besoin de comprendre comment faire fonctionner au moins une seule suite. Dans jasmine, je pourrais utiliser "ddescribe" ou "iit" au lieu de "describe" et "it" pour exécuter un seul test ou une seule suite. Jest est TELLEMENT gentil, j'ai juste besoin d'un flux de travail rapide maintenant.

Vous pouvez certainement écrire it.only et je pense que vous pouvez aussi faire describe.only .

Karma fait exactement ce que vous voulez et tout ce que vous avez à faire est d'ajouter un
karma.conf dans votre projet. Je n'avais pas réalisé que le karma supportait la réactivité
et navigateur. Vous pouvez désormais tester dans tous vos navigateurs en même temps.
J'ai créé un PR pour votre projet passe-partout.

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

Exécutez simplement « npm test » et karma lancera vos navigateurs et surveillera
changements.

Le mar. 12 août 2014 à 10h35, Tyrone Avnit [email protected]
a écrit:

Merci @iamrandys https://github.com/iamrandys. Développé un rapide
réact-composant-boilerplate
https://github.com/TYRONEMICHAEL/react-component-boilerplate qui utilise
Moka et Chai (le jasmin peut être facilement remplacé). Les tests sont extrêmement
rapide et vous obtenez l'avantage supplémentaire de Livereload. Utilisez comme vous le souhaitez.

-
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/facebook/jest/issues/116#issuecomment -51931532.

Utilisez le préprocesseur.js suivant pour éviter la transformation de fichiers non JSX en JSX. Tel quel, il ne traite que les fichiers .jsx qui contiennent le préfixe /** @jsx . Si vous souhaitez transformer JSX des fichiers .js , supprimez simplement la première partie de la condition if avant || (de sorte que seule la condition src.slice ... reste).

// 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);
  }
};

C'est quand même un peu lent.

Extrait intéressant @sqs. Corrigez-moi si je me trompe, mais n'aurait-il toujours pas besoin de parcourir chaque fichier et de vérifier s'il a besoin de le convertir ? J'ai eu beaucoup de succès avec le suivant - réagir-composant-boilerplate . Les tests s'exécutent en fait assez rapidement.

Très agréable. Cela a réduit le temps de 9,3 s à 4,7 s. C'est pour un seul test. Je vais quand même devoir rester avec Karma où c'est beaucoup plus rapide (100 tests prennent moins d'une seconde). De plus, Karma surveillera les changements pendant que vous travaillez et testera votre code dans plusieurs navigateurs, mais j'aime bien la moquerie automatique de Jest. Créer manuellement des espions à l'aide de rewireify est un travail supplémentaire, mais vous avez un contrôle total.

Oui, je vous comprends peut-être mal, mais c'est ce que je voulais dire en supprimant la vérification de .jsx si vous avez des fichiers .js avec jsx et que vous souhaitez détecter en fonction de l'en-tête pragma.

Envoyé de mon iPhone

Le 28 août 2014, à 23h45, Tyrone Avnit [email protected] a écrit :

Extrait intéressant @sqs. Corrigez-moi si je me trompe, mais n'aurait-il toujours pas besoin de parcourir chaque fichier et de vérifier s'il a besoin de le convertir ? J'ai eu beaucoup de succès avec ce qui suit - react-component-boilerplate. Les tests s'exécutent en fait assez rapidement.

-
Répondez directement à cet e-mail ou consultez-le sur GitHub.

Salut! Je travaille sur --watch pour plaisanter et j'essaie généralement de faire en sorte que cela aille plus vite. Fera rapport bientôt.

le premier run pour moi prend environ 5s (je n'ai qu'un test, je viens juste de commencer). Après cela, chaque exécution supplémentaire prend environ 1,2 à 1,5 s.

Il semble qu'une quantité décente de ce temps soit consacrée au chargement du cache de hâte (qui pour mon projet est déjà un fichier de 4 Mo.

J'attends avec impatience le travail de --watch , mais je me demande aussi ce qui se passe qui nécessite 1,2 seconde de temps de chargement pour exécuter un test ? Je ne sais rien de ce que fait la hâte et pourquoi la plaisanterie l'utilise, donc je suis assez paumé.

Haste prend en charge une variante du format de module CommonJS où les noms de module sont de niveau supérieur plutôt que relatifs. Cela signifie que nous devons connaître les modules (et les dépendances) à l'avance avant d'exécuter le programme, sinon il serait incroyablement inefficace de parcourir le système de fichiers pour rechercher un module sur chaque require . Cependant, nous réalisons que la plupart des gens utilisent le format de module relatif (à la node.js) et nous voulons supprimer la dépendance implicite sur Haste (à moins qu'une option ne soit fournie) et cela devrait le rendre plus rapide.

@amasad ça sonne bien. J'ai essayé intern.js et il exécute un test unitaire régulier de la ligne cmd pour terminer en quelques ms. Pensez-vous que la plaisanterie pourrait arriver aussi vite? Et avez-vous pensé à extraire la partie automocking pour qu'elle soit utilisable dans d'autres frameworks comme jasmin ou moka ?

J'ai trouvé des fichiers nécessitant (en particulier 'react/addons' et le module testé) une fois sous le rappel de description, au lieu de plusieurs fois dans les rappels beforeEach ou it fait une énorme différence.

Évidemment, j'utilise coffee-script et non jsx, mais cela évite à la fois le travail du préprocesseur et le travail de plaisanterie pour simuler automatiquement les appels require .

__tests__/login_fields.coffee (3.013s) (aïe !)

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
    ...

mais ça va beaucoup plus vite avec...
__tests__/login_fields.coffee (0.604s) (pas 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
  ...

Mes tests durent 14 secondes, même après avoir utilisé toutes les optimisations recommandées jusqu'à présent. Même avec 16 Go de RAM et SSD. Jest est totalement inutilisable dans son état actuel. Désolé, je suis passé à Karma.

J'ai trouvé un grand succès avec karma, moka, chai, sinon, rewireify et aliasify. Plus de 300 tests exécutés en 1/2 seconde. Le meilleur de tous, React est INCROYABLE !!!!! L'équipe ADORE ça et a développé de très bonnes choses avec. C'est tellement propre et facile à entretenir. Énorme différence avec tout ce que nous avons jamais utilisé.

Je viens de tomber dessus moi-même. Les tests s'exécutent _RÉELLEMENT_ lentement. Le problème avec les tests lents est que les développeurs les désactivent ou ne les exécutent qu'une partie du temps. Une idée de ce qui cause cela ? Comment puis-je aider?

J'ai eu exactement ce problème - les tests ont duré environ 17 secondes pour s'exécuter initialement, puis 4 secondes après la mise en cache. Il s'avère que mon répertoire de construction et les modules externes n'ont pas été correctement exclus. La définition de l'option de configuration testPathDirs pour qu'elle pointe vers le répertoire source a réduit les temps d'exécution à 0,5 seconde.

Cela a fonctionné pour moi en utilisant 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);
  }
};

Je viens de commencer à utiliser Jest également - je teste simplement des modules JavaScript réguliers (pas de JSX / React) et Jest est très lent. J'aime l'idée des tests en ligne et des moqueries intégrées, mais c'est tellement lent que Mocha me manque. Je ne sais pas quel est le coupable... ce n'est pas la recherche dans l'arborescence des répertoires qui cause la lenteur de la vitesse. Si je spécifie le fichier directement, c'est toujours super lent.

Des idées sur au moins la cause de la lenteur? (Je n'utilise pas JSX / CoffeeScript ; l'auto-mocking est désactivé)

L'exemple d'origine n'a jamais fonctionné pour moi car le premier argument est toujours retourné vrai.

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 merci pour les bonnes solutions de contournement, raccourcissez les tests 10s+ à 2+. ces solutions de contournement m'ont fait penser que nous devrions peut-être utiliser l'extension _.jsx/_.react.js pour nos fichiers de réaction, je pense que cela pourrait également aider lors de l'utilisation de reactify.

Pour être honnête, en passant par Grunt, j'obtenais toujours des temps de +20s, j'ai eu
Réagissez en travaillant avec Karma et le temps total est d'environ +4/5 secondes.

Tout à l'intérieur d'une VM cependant

Juste pour faire un retour là-dessus. Nous avons testé React avec Karma/Mocha et nous sommes à près de 700 tests et cela prend environ 4 secondes pour exécuter tous les tests. Nous devons gérer les simulacres, mais cela en vaut la peine. React a été INCROYABLE. Impeccable et agréablement stable. Changeur de jeu! Notre équipe ne pouvait pas imager en utilisant autre chose.

Je n'ai jamais réussi à faire en sorte que Jest soit rapide. J'utilise du moka. Si Jest était rapide, je
l'aurait utilisé à la place.

Le jeu. 5 février 2015 à 12:17, Gil Birman [email protected]
a écrit:

@iamrandys https://github.com/iamrandys voudriez-vous expliquer dans
plus de détails comment tu as réussi à faire une blague si vite ?

-
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/facebook/jest/issues/116#issuecomment -73097182.

Merci @iamrandys J'avais supprimé mon "comment as-tu fait pour être rapide ?" question après avoir réalisé que j'avais mal lu votre message (mais vous avez répondu en même temps)... de toute façon, c'est dommage, je suppose que la plaisanterie devrait toujours être considérée comme pas si prête pour une utilisation en production.

les solutions de contournement/modifications de @haihappen et @darcyadams m'ont aidé à réduire le temps de test de 3,5 secondes à environ 1 seconde pour un seul test. Cela ne prend pas en compte le temps de démarrage apparent, qui semble être d'environ 1 seconde également. Cela semble beaucoup trop lent pour être efficace dans le travail quotidien, alors je suppose que je vais jeter un œil au combo moka/karma. J'aime la philosophie de Jest de se moquer de tout par défaut, mais l'avantage n'est tout simplement pas là.

J'ai le même problème : je n'ai eu que 3 tests dans un petit projet et ils prennent 3 secondes.

L'amélioration des performances est-elle proche de la feuille de route du projet ?

BTW : J'ai trouvé un moyen (assez bidon) de réexécuter des tests unitaires uniquement pour les fichiers qui ont changé. Cela les rend à nouveau assez rapides, car il n'y a généralement qu'un seul test à exécuter. Je l'ai mis ici : https://gist.github.com/mik01aj/fefb7718331e5454b9d1

Strange Jest n'a pas été mentionné lors de la conférence React.js 2015.

testPathDirs semble être le coupable. Spécifiez comme ceci dans package.json :

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

@adjavaherian faites attention à cela si vous utilisez la moquerie automatique : https://github.com/facebook/jest/issues/176

En fait, attendez-vous à ce que l'auto-mocking se brise de manière subtile et frustrante si votre testPathDirs ne couvre pas vos dépendances.

Ces préoccupations me font penser que nous pourrions faire quelque chose de mal avec notre configuration de test. Je me trompe peut-être, mais pour autant que je sache, nous utilisons tous des éléments tels que : var component = React.createFactory(require("component/path")) avec d'autres modules requis dans beforeEach test. Cela ne doit certainement pas être nécessaire pour tous les tests. Je veux dire qu'une usine devrait produire un nouveau composant à chaque fois. Si je déplace l'exigence en dehors de la vitesse de test de bloc beforeEach augmente 10x. Malheureusement, dans ce cas, certains tests échouent étrangement et je ne sais pas pourquoi.

Je ne sais pas si cela aide. Les pensées?

Ce serait bien si le temps de prétraitement n'était pas pris en compte dans le temps d'exécution du test signalé. Un peu injuste de voir rouge quand la majeure partie de ce travail vient d'une étape de transformation.

Salut les gars,

J'ai le même problème. J'ai même des cas de test qui prennent environ 1 minute à exécuter :(

Je ne sais pas par où commencer pour profiler le problème de performance, un indice ?

METTRE À JOUR

J'ai corrigé ce problème qui n'apparaissait que dans mon environnement VM (cf : http://stackoverflow.com/a/13703132). Maintenant, les tests sont toujours plus lents que ce à quoi je m'attendais, mais bien plus rapides qu'avant le correctif vagrant (60 secondes -> 6 secondes pour ma combinaison de test)

Si la vitesse est toujours un problème, je suggère de passer à Moka. Nous avons eu beaucoup de succès avec ce fork, qui explique comment configurer des tests pour des déploiements React simples à complexes. https://github.com/adjavaherian/mocha-react Nous effectuons régulièrement plus de 100 tests en 3 secondes environ.

Je suis d'accord que Moka est la voie à suivre. Jusqu'à près de 900 tests et cela prend environ 4 secondes.

Le 23 avril 2015, à 16h53, Amir Djavaherian [email protected] a écrit :

Si la vitesse est toujours un problème, je suggère de passer à Moka. Nous avons eu beaucoup de succès avec ce fork, qui explique comment configurer des tests pour des déploiements React simples à complexes. https://github.com/adjavaherian/mocha-react Nous effectuons régulièrement plus de 100 tests en 3 secondes environ.

-
Répondez directement à cet e-mail ou consultez-le sur GitHub.

Même expérience, je viens de configurer Jest avec un seul test (en utilisant JSX) et cela prend environ 3 secondes, c'est beaucoup.

@iamrandys, ça vous dérange de montrer un exemple de votre configuration ? Cela semble être le combo parfait.

@amasad Existe-t-il une option avec Jest pour créer un cache pour les fichiers compilés similaire à ce que le babel-loader autorise dans l'option cacheDirectory ? - https://github.com/babel/babel-loader#options

Ce qui ralentit Jest pour moi, ce n'est pas la compilation mais plutôt le démarrage des processus du pool de travail. Tous mes tests passent en moins de 0,05 seconde sauf les premiers, qui durent environ 4 secondes.
https://github.com/jeffmo/node-worker-pool
https://github.com/facebook/jest/blob/master/src/TestRunner.js#L376

@songawee Ce n'est pas le cas, mais vous voulez envoyer un PR pour l'avoir en option ? Je ne pense pas que nous devrions l'avoir activé par défaut car il est parfois impossible de savoir quand casser le cache. Par exemple, si vous modifiez les options de votre compilateur, le cache doit être réinitialisé. Une autre option consiste à avoir une option de réinitialisation du cache en plus de la mise en cache.

@doodzik êtes-vous sûr que c'est le pool de travailleurs et non le node-haste indiquant et lisant les modules ?

@amasad Ce que j'ai fait, c'est mesurer le temps qu'il fallait à chaque étape de l'exécution de jest pour terminer.
Et le node-worker-pool était le dernier cas où les tests étaient lents.
Il se peut que mes découvertes ne soient que le symptôme et non la racine du problème.
Mais je n'avais pas eu le temps de l'analyser correctement.

Mes tests ressemblent actuellement à ceci :

Mes tests de réaction sont lents (ceux du dossier des exemples). Ce dont je parle, ce sont les tests de non-réaction.

+1

Pareil ici. Les tests sont très très lents :déçu:

Je pensais que c'était seulement moi qui faisais face au problème. C'est la première fois que j'utilise Jest et je n'obtiens pas non plus de résultat de test rapide. Vous vous demandez comment Facebook fait le test avec Jest ?

Ma question sur les améliorations apportées à Jest aux gars de React lors de la session de questions-réponses de la conférence React Europe - https://youtu.be/CRJZBZ_-6hQ?t=363

Passé à Moka + Sinon. Jamais été aussi heureux.

Le 31 août 2015 à 17h45, Alan Rubin [email protected] a écrit :

Ma question sur les gars de Jest to the React à la conférence React Europe Q&A
séance - https://youtu.be/CRJZBZ_-6hQ?t=363

-
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/facebook/jest/issues/116#issuecomment -136394910.

J'ai le même problème. Les tests Jest prennent juste beaucoup de temps et le temps d'exécution varie en fait. Que ce soit pour les exécuter en parallèle ou dans un seul processus (--runInBand) n'avait pas d'importance. Il ne semble pas s'agir d'un conflit de ressources entre les processus de travail.

J'ai créé des vidages de processeur avec le profileur v8 (https://github.com/node-inspector/v8-profiler) et j'ai constaté que la plupart du temps semble être passé à se moquer des modules. C'est-à-dire que 25% du temps d'exécution de mon test unitaire est passé dans jest-cli/src/lib/utils.js#runContentWithLocalBindings.

des mises à jour de performances ? vient de prendre jest avec es6 et babel-jest, mais en exécutant 2 tests simples en > 10 secondes :-(
essayé beaucoup d'idées de ce fil pour accélérer, mais rien n'a fonctionné ...

Nous nous concentrerons sur cela bientôt. Nous sommes un peu submergés par le travail sur la plaisanterie en ce moment, mais nous nous engageons à le rendre plus impressionnant.

Y a-t-il des tâches pour lesquelles la communauté pourrait aider ?

+1

La plus grande aide en ce moment serait en fait d'améliorer la documentation, le site Web, de résoudre les problèmes et d'aider les gens en open source.

Une chose que nous avons faite pour accélérer nos tests JEST dans le pipeline de construction a été de remplacer notre machine monocœur par une machine multicœur. Par défaut, jest génère autant de travailleurs que de threads matériels sont disponibles. Si cela n'est pas disponible, vous pouvez jouer manuellement avec '-w' (maxWorkers). Vous pouvez également gagner en accélération sur un seul cœur.

En fin de compte, nous avons constaté que les modules moqueurs sont très coûteux (voir mon commentaire ci-dessus) et entraînent la majorité du temps d'exécution.

Jest avec es6 pour moi est complètement inutilisable. il faut plus de 10 secondes pour démarrer, puis il faut 2 secondes pour exécuter le seul test que j'ai pour le moment. Je m'attendais à beaucoup plus, retournant au karma :(

Nous travaillons actuellement sur le remplacement de node-haste par un nouveau résolveur de module, ce qui devrait résoudre ce problème.

Salut tout le monde. Y a-t-il des nouvelles sur ce problème ?

Bonjour, Jest est-il adapté aux tests non React ? J'aimerais avoir une norme commune pour les applications réactives et non réactives dans notre équipe.

Jest est un testeur universel et vous n'êtes en aucun cas obligé d'utiliser React. :) Jetez un œil à l'un des exemples !

Salut à tous, quelques informations vraiment intéressantes ici. Je rencontre également des problèmes avec les tests qui s'exécutent lentement. J'ai actuellement 13 tests prenant environ 15 secondes à exécuter.

J'ai trouvé que l'ajout de "testPathDirs": ["<rootDir>/path/to/tests/"] à notre fichier packages.json aidait à améliorer considérablement le temps de démarrage.

@cpojer Avez-vous une mise à jour pour nous concernant le nouveau résolveur de module amélioré ? J'espère vraiment que ce sera la clé pour que les tests s'exécutent beaucoup plus rapidement

Ce travail se passe dans #599.

Merci @cpojer 😀
J'ai hâte de voir le Haste2 fini

Les mêmes tests utilisant du moka se sont déroulés en 44 ms pour moi où la plaisanterie a pris 6 secondes complètes.

Il m'a fallu environ 15 minutes pour changer mes 6 fichiers de test initiaux en utilisant jest en utilisant Mocha , jsdom et sinon .

Bonne nouvelle à tous, je fusionne le #599 aujourd'hui et cela devrait enfin éliminer le démarrage lent.

Ok, cela devrait enfin être corrigé dans Jest 0.9. Désolé que cela ait pris si longtemps mais il y avait un peu de clownerie dans Jest :)

Voir https://github.com/facebook/react/pull/6052 sur la façon dont les tests React eux-mêmes ont été accélérés. Si vous souhaitez essayer cette amélioration, consultez les commentaires dans #599. Il est actuellement étiqueté comme jest-cli@next jusqu'à voir s'il y a des bogues que les gens en open source pourraient rencontrer. Je clos ce problème comme résolu.

npm install jest-cli@next si vous souhaitez exécuter cette nouvelle version (plutôt que jest@next @cpojer)

oh ouais, je fais toujours cette erreur :) J'ai édité mon commentaire original.

@cpojer après la mise à niveau à l'aide de npm install jest-cli@next J'ai des problèmes pour spécifier dontMock . J'entends par là, avant la mise à jour (en utilisant [email protected]) cette ligne fonctionne correctement :

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

puis après la mise à jour vers la 0.9.0, le même appel entraîne la moquerie du module

@steinbachr qui devrait probablement entrer dans un problème distinct. Ce serait génial si vous pouviez fournir une reproduction, je n'ai pas vu ce problème survenir sur FB !

merci @cpojer , problème créé ici