Jest: Langsam reagierende Tests

Hallo Tyron. Hatte dieses Problem mit 20+ Sekunden für eine Datei :)
Die Sache war, dass ich konfiguriert habe, nur 'jest' im Stammverzeichnis auszuführen. Und es gibt viele Unterverzeichnisse, die Jest auf Tests überprüft hat. Die Angabe eines Pfads für Tests hat diese Zeit jetzt um mehr als das Zehnfache reduziert. Und ich habe auch einen Kaffee-Preprozessor. In package.json
"Skripte": {
....
"test": "jest path/to/modules/to/test"
}

Übrigens, bereitest du Kaffee vor oder was? :)

Danke, dass du mir @gothy gemeldet hast. Ich verwende normales JS mit JSX. Ich führe meine Tests gerade durch den JSX-Präprozessor wie im Beispiel (https://github.com/facebook/jest/tree/master/examples/react). Die Ausführung des Beispiels dauert ebenfalls etwa 2,5 - 3 Sekunden. Das jQuery-Beispiel dauert weniger als eine Sekunde. Soll der JSX-Präprozessor so viel Zeit bei der Verarbeitung Ihrer JSX-Dateien in Anspruch nehmen?

Reaktionstest

jQuery-Test

Ah, ich habe es nicht für JSX verwendet. Zu diesem Prozessor kann ich nichts sagen. Vielleicht ist es tatsächlich langsam. Ich habe mein Problem mit Verzeichnissen in einem echten Projekt mit vielen alten Sachen gefunden :)

Ich hatte ein ähnliches Problem mit dem Coffeescript-Präprozessor. Ich denke, das Problem hier ist, dass der Präprozessor versucht, auch Ihre Abhängigkeiten zu verarbeiten. Wenn Sie viele Dinge benötigen, wird es langsamer.

Ich erlebe definitiv auch langsame Tests mit Scherz :(

Ich erlebe das gleiche. Ich glaube nicht, dass es mit der Vorverarbeitung zu tun hat (die JSX-Verarbeitung dieser kleinen Datei ist schnell). Ich habe den gesamten Code im Beispieltest mit Ausnahme einer der folgenden require-Anweisungen auskommentiert und der Test dauert immer noch 4 Sekunden. Sobald ich sie auskommentiere, dauert der Test 0,1s. Ich habe ein wenig gegraben und es sieht so aus, als ob der HasteModuleLoader 490 erforderliche Pakete (_shouldMock()) verarbeiten muss und sie nicht verspotten muss, wenn Sie die Reak-/Addons benötigen.

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

oder

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

Ich habe das folgende var React = require('react/addons'); und die Dateien immer noch durch den Präprozessor laufen lassen. Ich habe vielleicht 0,2 Sekunden Verbesserung. Wenn ich den Präprozessor entfernt habe, erhalte ich folgende Ergebnisse:

Mit dem JSX-Präprozessor

Ohne den JSX-Präprozessor

Ich bevorzuge Mocha gegenüber Jasmine und beschloss, ein Gulpfile einzurichten, das die Reaktionskomponente erstellt und dann die Mocha-Testsuite durchläuft (Snippet unten).

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

Es muss die JSX-Datei immer noch mit Reaktify vorverarbeiten, entfernt aber die Warnmeldung für langsame Tests. Die Laufzeit beträgt also noch knapp 2 Sekunden, der eigentliche Test beträgt aber ca. 32ms. Entscheiden Sie immer noch, ob sich die Verwendung von JSX lohnt.

Oh, du hast Recht. Ich habe das Jest-Reaktion-Beispiel ohne JSX getestet und es ging von fast 4 Sekunden auf 0,75 Sekunden zurück. Lässt mich wirklich darüber nachdenken, ob es sich lohnt, JSX zu verwenden. Bei einem großen Projekt wird es ziemlich schnell langsam, es sei denn, ich habe viele verschiedene Pakete. Ich frage mich, ob der Präprozessor auf allen 490-Anforderungen ausgeführt wird und nicht nur auf dieser einzelnen Datei. Für diese einfache Komponente sollte es auf keinen Fall 3 Sekunden dauern.

Wie auch immer, ich brauche wirklich wirklich, dass meine Tests für meinen Workflow schnell sind. Ich muss noch herausfinden, wie man zumindest eine einzelne Suite betreibt. In Jasmin könnte ich "ddescribe" oder "iit" anstelle von "describe" und "it" verwenden, um einen einzelnen Test oder eine einzelne Suite auszuführen. Spaß ist SO nett, ich brauche jetzt nur einen schnellen Workflow.

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 hatte recht. Der gesamte erforderliche Code wird durch den Präprozessor ausgeführt, nicht nur die JSX-Dateien.

Es sieht so aus, als ob die schnellste Lösung darin besteht, schlucken, beobachten und reagieren, um nur die geänderten JSX-Dateien während Ihrer Arbeit zu verarbeiten. Wir können dann nur die Tests angeben, die ich auch ausführen möchte. Auf diese Weise werden die JSX-Dateien nur einmal verarbeitet und ich habe die Kontrolle darüber, welche Tests ausgeführt werden. So etwas wäre wirklich schön für einen Testworkflow.

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

Watchify überwacht dann alle Änderungen, von denen diese Tests abhängen, und verarbeitet dann nur die Änderungen und führt dann nur die Tests aus, mit denen ich arbeite.

@iamrandys Ich stimme dir zu 100% zu. Jest und React sind großartig, aber das Kompilieren von JSX in JS ist ein großes Hindernis. Sind Sie nur neugierig, wie Gulp das Problem lösen wird, dass Ihre erforderlichen Dateien (nicht JSX) durch den JSX-Präprozessor laufen? Schlagen Sie etwa Folgendes vor - http://blog.avisi.nl/2014/04/25/how-to-keep-a-fast-build-with-browserify-and-reactjs/ ?

Ja, ich denke über eine Art Caching-Layer mit dem gulp-Plugin nach
arbeiten an

Am 11. August 2014 um 08:35 Uhr schrieb Tyrone Avnit [email protected] :

@iamrandys https://github.com/iamrandys Ich stimme dir zu 100% zu. Scherz und
React sind großartig, aber die Kompilierung von JSX in JS ist ein großes Hindernis. Gerade
neugierig, wie Gulp das Problem lösen wird, Ihre erforderlichen Dateien zu haben (Non
JSX) durch den JSX-Präprozessor ausgeführt? Schlagen Sie etwas vor
wie folgendes? -
http://blog.avisi.nl/2014/04/25/how-to-keep-a-fast-build-with-browserify-and-reactjs/
?

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/facebook/jest/issues/116#issuecomment -51749798.

Genau, mit gulp und watchify ist das Reagieren erstaunlich schnell. Einwerfen
gulp-livereload, um Ihren Browser nach jeder Änderung zu aktualisieren und Sie haben ein
erstaunliche Entwicklungsumgebung. Sie nehmen jede Änderung vor, speichern und Sie fast
sehen Sie sofort die Änderungen in all Ihren geöffneten Browsern und auf allen Geräten. Jetzt ich
brauche nur das gleiche für mein TDD.

Es ist ungefähr so, aber verwenden Sie Reactify anstelle von hbsfy.
https://gist.github.com/benhowdle89/9533185

Am Mo, 11. August 2014 um 2:35 Uhr, Tyrone Avnit [email protected]
schrieb:

@iamrandys https://github.com/iamrandys Ich stimme dir zu 100% zu. Scherz und
React sind großartig, aber die Kompilierung von JSX in JS ist ein großes Hindernis. Gerade
neugierig, wie Gulp das Problem lösen wird, Ihre erforderlichen Dateien zu haben (Non
JSX) durch den JSX-Präprozessor ausgeführt? Schlagen Sie etwas vor
wie folgendes? -
http://blog.avisi.nl/2014/04/25/how-to-keep-a-fast-build-with-browserify-and-reactjs/
?

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/facebook/jest/issues/116#issuecomment -51749798.

Danke @iamrandys. Entwickelt eine schnell reagierende Komponenten-Kesselplatte, die Mokka und Chai verwendet (Jasmin kann leicht ersetzt werden). Tests sind extrem schnell und Sie erhalten den zusätzlichen Vorteil von Livereload. Verwenden Sie nach Belieben.

Wie auch immer, ich brauche wirklich wirklich, dass meine Tests für meinen Workflow schnell sind. Ich muss noch herausfinden, wie man zumindest eine einzelne Suite betreibt. In Jasmin könnte ich "ddescribe" oder "iit" anstelle von "describe" und "it" verwenden, um einen einzelnen Test oder eine einzelne Suite auszuführen. Spaß ist SO nett, ich brauche jetzt nur einen schnellen Workflow.

Sie können definitiv it.only schreiben und ich glaube, Sie können auch describe.only schreiben.

Karma macht genau das, was Sie wollen und alles was Sie tun müssen, ist ein hinzuzufügen
karma.conf-Datei in Ihr Projekt. Ich wusste nicht, dass Karma reaktiviert wird
und browserify. Jetzt können Sie in allen Ihren Browsern gleichzeitig testen.
Ich habe eine PR für Ihr Boilerplate-Projekt erstellt.

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

Führen Sie einfach 'npm test' aus und Karma wird Ihre Browser starten und nach Ausschau halten
Änderungen.

Am Dienstag, 12. August 2014 um 10:35 Uhr, Tyrone Avnit [email protected]
schrieb:

Danke @iamrandys https://github.com/iamrandys. Entwickelt eine schnelle
Reaktionskomponenten-Kesselplatte
https://github.com/TYRONEMICHAEL/react-component-boilerplate die verwendet
Mokka und Chai (Jasmin kann leicht ersetzt werden). Tests sind extrem
schnell und Sie erhalten den zusätzlichen Vorteil von Livereload. Verwenden Sie nach Belieben.

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/facebook/jest/issues/116#issuecomment -51931532.

Verwenden Sie die folgende preprocessor.js, um eine JSX-Transformation von Nicht-JSX-Dateien zu vermeiden. Es verarbeitet nur .jsx Dateien, die das Präfix /** @jsx . Wenn Sie .js Dateien mit JSX transformieren möchten, entfernen Sie einfach den ersten Teil der if-Bedingung vor der || (damit nur die src.slice ... Bedingung übrig bleibt).

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

Allerdings immer noch etwas langsam.

Interessanter Ausschnitt @sqs. Korrigieren Sie mich Wenn ich falsch liege, aber müsste es trotzdem nicht jede Datei durchsuchen und prüfen, ob sie konvertiert werden muss? Ich hatte viel Erfolg mit der folgenden - React-Component-Boilerplate . Tests laufen eigentlich ziemlich schnell.

Sehr schön. Dadurch verkürzte sich die Zeit von 9,3 s auf 4,7 s. Dies ist für einen einzelnen Test. Ich muss trotzdem bei Karma bleiben, wo es viel schneller ist (100 Tests dauern weniger als eine Sekunde). Außerdem wird Karma während der Arbeit nach Änderungen Ausschau halten und Ihren Code in mehreren Browsern testen, aber ich liebe Jests automatische Verspottung. Das manuelle Erstellen von Spionen mit rewireify ist zusätzliche Arbeit, aber Sie haben die vollständige Kontrolle.

Ja, ich verstehe Sie vielleicht falsch, aber das meinte ich mit dem Entfernen der Überprüfung auf .jsx, wenn Sie .js-Dateien mit jsx haben und basierend auf dem Pragma-Header erkennen möchten.

von meinem Iphone gesendet

Am 28. August 2014 um 23:45 Uhr schrieb Tyrone Avnit [email protected] :

Interessanter Ausschnitt @sqs. Korrigieren Sie mich Wenn ich falsch liege, aber müsste es trotzdem nicht jede Datei durchsuchen und prüfen, ob sie konvertiert werden muss? Ich hatte viel Erfolg mit dem folgenden - Reaktions-Komponenten-Kesselplatte. Tests laufen eigentlich ziemlich schnell.

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an.

Hi! Ich arbeite an --watch zum Scherz und versuche im Allgemeinen, dies schneller zu machen. Werde bald wieder berichten.

der erste Durchlauf dauert bei mir ca. 5s (ich habe nur einen Test, ich fange gerade erst an). Danach dauert jeder weitere Durchlauf ca. 1,2-1,5s.

Es sieht so aus, als würde ein anständiger Teil dieser Zeit damit verbracht, den Haste-Cache zu laden (der für mein Projekt bereits eine 4-Meg-Datei ist.

Ich freue mich auf die --watch Arbeit, aber ich frage mich auch was los ist das 1,2 Sekunden Ladezeit benötigt um einen Test auszuführen? Ich weiß nichts darüber, was Eile macht und warum Scherz es benutzt, also bin ich ziemlich ahnungslos.

Haste unterstützt eine Variante des CommonJS-Modulformats, bei der die Modulnamen nicht relativ, sondern auf oberster Ebene sind. Das bedeutet, dass wir die Module (und Abhängigkeiten) im Voraus kennen müssen, bevor wir das Programm ausführen, sonst wäre es unglaublich ineffizient, das Dateisystem zu durchsuchen, um auf jedem require nach einem Modul zu suchen. Wir stellen jedoch fest, dass die meisten Leute ein relatives Modulformat (a la node.js) verwenden, und wir möchten die implizite Abhängigkeit von Haste entfernen (es sei denn, eine Option wird bereitgestellt) und dies sollte es schneller machen.

@amasad das klingt toll. Ich habe intern.js ausprobiert und es führt einen regelmäßigen Komponententest von der cmd-Zeile bis zum Abschluss in wenigen ms durch. Glaubst du, Witze könnten so schnell ankommen? Und haben Sie darüber nachgedacht, den Automocking-Anteil zu extrahieren, damit er in anderen Frameworks wie Jasmin oder Mokka verwendet werden kann?

Ich habe festgestellt, dass es einen großen Unterschied macht, Dateien (insbesondere 'react/addons' & das getestete Modul) einmal unter dem describe-Callback zu erfordern, anstatt wiederholt in beforeEach oder it Callbacks.

Offensichtlich verwende ich Coffee-Script und nicht jsx, aber das spart sowohl Präprozessorarbeit als auch Scherzarbeit, um require Aufrufe automatisch zu simulieren.

__tests__/login_fields.coffee (3.013s) (autsch!)

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

aber es geht viel schneller mit...
__tests__/login_fields.coffee (0.604s) (nicht schlecht)

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

Meine Tests sind 14 Sekunden lang, selbst nachdem ich alle bisher empfohlenen Optimierungen verwendet habe. Auch mit 16GB RAM und SSD. Jest ist in seinem jetzigen Zustand völlig unbrauchbar. Entschuldigung, Wechsel zu Karma.

Ich habe großen Erfolg mit Karma, Mokka, Chai, Sinon, Rewireify und Aliasify gefunden. Über 300 Tests laufen in 1/2 einer Sekunde. Das Beste von allem React ist ERSTAUNLICH!!!!! Das Team LIEBT es und hat einige wirklich gute Sachen damit entwickelt. Es ist so sauber und wartbar. Riesiger Unterschied zu allem, was wir je benutzt haben.

Bin gerade selbst darauf gestoßen. Tests laufen _WIRKLICH_ langsam. Das Problem bei langsamen Tests ist, dass Entwickler sie deaktivieren oder nur zeitweise ausführen. Irgendeine Idee, was das verursacht? Wie kann ich helfen?

Ich hatte genau dieses Problem - Tests dauerten anfangs etwa 17 Sekunden und dann 4 Sekunden nach dem Caching. Es stellt sich heraus, dass mein Build-Verzeichnis und externe Module nicht richtig ausgeschlossen wurden. Wenn die Konfigurationsoption testPathDirs so eingestellt wird, dass sie auf das Quellverzeichnis verweist, wurden die Laufzeiten auf 0,5 Sekunden reduziert.

Dies hat bei mir mit React v0.12+ funktioniert:

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


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

    return ReactTools.transform(src);
  }
};

Ich habe auch gerade angefangen, Jest zu verwenden - nur normale JavaScript-Module (kein JSX / React) zu testen, und Jest ist böse langsam. Ich liebe die Idee von Inline-Tests und eingebautem Spott, aber es ist so schmerzhaft langsam, dass ich Mocha vermisse. Ich bin mir nicht sicher, was der Schuldige ist ... es ist nicht die Suche im Verzeichnisbaum, die die langsame Geschwindigkeit verursacht. Wenn ich die Datei direkt angebe, ist sie immer noch super langsam.

Irgendwelche Ideen auf zumindest die Ursache der Langsamkeit? (Ich verwende kein JSX / CoffeeScript; Automocking ist deaktiviert)

Das ursprüngliche Beispiel hat bei mir nie funktioniert, da das erste Argument immer true zurückgegeben hat.

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 danke für die netten Workarounds,

Um ehrlich zu sein, habe ich bei Grunt immer noch Zeiten von +20s bekommen, hab
Reagiere bei der Arbeit mit Karma und die Gesamtzeit beträgt etwa +4/5 Sekunden.

Aber alles in einer VM

Nur um darüber Bericht zu erstatten. Wir haben die Reaktion mit Karma/Mocha getestet und sind bei fast 700 Tests und es dauert ungefähr 4 Sekunden, um alle Tests durchzuführen. Wir müssen Spott rächen, aber es lohnt sich. Die Reaktion war ERSTAUNLICH. Einwandfrei und erfrischend stabil. Spielwechsler! Unser Team konnte nicht mit etwas anderem bildgeben.

Ich habe Jest nie dazu gebracht, schnell zu sein. Ich verwende Mokka. Wenn Jest schnell war, ich
hätte es stattdessen verwendet.

Am Do, 5. Februar 2015 um 12:17 Uhr, Gil Birman [email protected]
schrieb:

@iamrandys https://github.com/iamrandys würde es dir etwas ausmachen , es zu erklären
Genaueres, wie Sie es geschafft haben, so schnell Scherze zu machen?

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/facebook/jest/issues/116#issuecomment -73097182.

Danke @iamrandys, ich hatte mein "Wie hast du

Die Problemumgehungen /Änderungen von @darcyadams haben mir geholfen, die Testzeit für einen einzelnen Test von 3,5 Sek. auf etwa 1 Sek. zu

Ich habe das gleiche Problem: Ich habe nur 3 Tests in einem kleinen Projekt und sie dauern 3 Sekunden.

Steht eine Verbesserung der Leistung in der Projekt-Roadmap in der Nähe?

Übrigens: Ich habe eine (ziemlich hackige) Möglichkeit gefunden, Komponententests nur für geänderte Dateien erneut auszuführen. Dadurch sind sie wieder ziemlich schnell, da normalerweise nur ein Test ausgeführt werden muss. Ich habe es hier abgelegt: https://gist.github.com/mik01aj/fefb7718331e5454b9d1

Strange Jest wurde auf der Konferenz von React.js 2015 nicht erwähnt.

testPathDirs scheint der Täter zu sein. Geben Sie in package.json Folgendes an:

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

@adjavaherian sei vorsichtig damit, wenn du automatisches Mocking verwendest: https://github.com/facebook/jest/issues/176

Erwarten Sie tatsächlich, dass Automocking auf subtile und frustrierende Weise unterbrochen wird, wenn Ihr testPathDirs Ihre Abhängigkeiten nicht abdeckt.

Diese Bedenken lassen mich vermuten, dass wir mit unserem Testaufbau etwas falsch machen könnten. Ich könnte mich hier irren, aber soweit ich weiß, verwenden wir alle Dinge wie: var component = React.createFactory(require("component/path")) zusammen mit anderen erforderlichen Modulen innerhalb von beforeEach test. Dies muss sicherlich nicht für alle Tests notwendig sein. Ich meine, eine Fabrik sollte jedes Mal eine neue Komponente produzieren. Wenn ich die Anforderung außerhalb des Testgeschwindigkeit um das 10-

Nicht sicher, ob das hilft. Die Gedanken?

Es wäre schön, wenn die Vorverarbeitungszeit bei der gemeldeten Testausführungszeit ausgelassen würde. Irgendwie unfair, rot zu sehen, wenn der Großteil dieser Arbeit aus einem Transformationsschritt stammt.

Hallo Leute,

Ich habe das gleiche Problem. Ich habe sogar einige Testfälle, deren Ausführung etwa 1 Minute dauert:(

Ich weiß nicht, wo ich anfangen soll, das Leistungsproblem zu profilieren, irgendein Hinweis?

AKTUALISIEREN

Ich habe dieses Problem behoben, das nur in meiner VM-Umgebung auftrat (vgl.: http://stackoverflow.com/a/13703132). Jetzt sind die Tests immer noch langsamer als ich es erwarten würde, aber viel schneller als vor dem vagabundierenden Fix (60 Sekunden -> 6 Sekunden für meinen Testanzug)

Wenn die Geschwindigkeit immer noch ein Problem ist, schlage ich vor, zu Mocha zu wechseln. Wir haben mit diesem Fork viel Erfolg gehabt, der erklärt, wie man Tests für einfache bis komplexe React-Implementierungen einrichtet. https://github.com/adjavaherian/mocha-react Wir führen regelmäßig über 100 Tests in ca. 3 Sekunden durch.

Ich stimme zu, Mokka ist der richtige Weg. Bis zu fast 900 Tests und es dauert ungefähr 4 Sekunden.

Am 23. April 2015 um 16:53 Uhr schrieb Amir Djavaherian [email protected] :

Wenn die Geschwindigkeit immer noch ein Problem ist, schlage ich vor, zu Mocha zu wechseln. Wir haben mit diesem Fork viel Erfolg gehabt, der erklärt, wie man Tests für einfache bis komplexe React-Implementierungen einrichtet. https://github.com/adjavaherian/mocha-react Wir führen regelmäßig über 100 Tests in ca. 3 Sekunden durch.

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an.

Dieselbe Erfahrung, ich habe Jest nur mit nur einem Test (mit JSX) eingerichtet und es dauert ungefähr 3 Sekunden, das ist viel.

@iamrandys macht es Ihnen etwas aus, ein Beispiel für Ihr Setup zu zeigen? Scheint die perfekte Kombi zu sein.

@amasad Gibt es bei Jest eine Option, um einen Cache für kompilierte Dateien aufzubauen, ähnlich dem, was der babel-loader in der cacheDirectory-Option zulässt? - https://github.com/babel/babel-loader#options

Was den Scherz für mich langsam macht, ist nicht die Kompilierung, sondern das Hochfahren der Worker-Pool-Prozesse. Alle meine Tests bestehen in weniger als 0,05 Sekunden, mit Ausnahme der ersten, die etwa 4 Sekunden dauern.
https://github.com/jeffmo/node-worker-pool
https://github.com/facebook/jest/blob/master/src/TestRunner.js#L376

@songawee Sie möchten eine PR senden, um sie als Option zu haben? Ich denke nicht, dass wir es standardmäßig aktivieren sollten, da es manchmal unmöglich ist zu wissen, wann der Cache unterbrochen werden soll. Wenn Sie beispielsweise Ihre Compileroptionen ändern, sollte der Cache zurückgesetzt werden. Eine weitere Option besteht darin, zusätzlich zum Caching eine Reset-Cache-Option zu haben.

@doodzik bist du sicher, dass es der Worker-Pool ist und nicht das node-haste , das Module angibt und liest?

@amasad Was ich getan habe, war, die Zeit zu messen, die jeder Schritt beim Ausführen von jest bis zum Abschluss benötigte.
Und das node-worker-pool war das letzte Mal, wo die Tests langsam waren.
Es könnte sein, dass meine Ergebnisse nur das Symptom und nicht die Wurzel des Problems sind.
Aber ich hatte keine Zeit gehabt, es richtig zu analysieren.

Meine Tests sehen derzeit so aus:

Meine Reaktionstests sind langsam (die im Beispielordner). Was ich meine, sind die nicht reagierenden Tests.

+1

Hier gilt das gleiche. Tests sind sehr sehr langsam :enttäuscht:

Ich dachte, nur ich stehe dem Problem gegenüber. Es ist mein erstes Mal, dass ich Jest verwende und ich bekomme auch kein schnelles Testergebnis. Sie fragen sich, wie Facebook den Test mit Jest durchführt?

Meine Frage zu Jest-Verbesserungen an die React-Jungs bei der Q&A-Sitzung der React Europe-Konferenz - https://youtu.be/CRJZBZ_-6hQ?t=363

Auf Mokka + Sinon umgestellt. Nie glücklicher gewesen.

Am 31. August 2015 um 17:45 Uhr schrieb Alan Rubin [email protected] :

Meine Frage zu Jest an die React-Jungs auf der React Europe-Konferenz Q&A
Sitzung - https://youtu.be/CRJZBZ_-6hQ?t=363

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/facebook/jest/issues/116#issuecomment -136394910.

Ich habe das gleiche Problem. Jest-Tests nehmen einfach viel Zeit in Anspruch und die Ausführungszeit variiert tatsächlich. Ob sie parallel oder in nur einem Prozess (--runInBand) ausgeführt werden sollten, spielte keine Rolle. Es scheint kein Ressourcenkonflikt zwischen den Worker-Prozessen zu sein.

Ich habe mit dem v8-Profiler (https://github.com/node-inspector/v8-profiler) einige CPU-Dumps erstellt und festgestellt, dass die meiste Zeit damit verbracht wird, Module zu verspotten. Dh 25 % der Ausführungszeit meines Komponententests werden in jest-cli/src/lib/utils.js#runContentWithLocalBindings verbracht.

irgendwelche Leistungsupdates? habe gerade Spaß mit es6 und babel-jest aufgenommen, aber 2 einfache Tests in > 10 Sekunden ausgeführt :-(
Ich habe viele Ideen aus diesem Thread ausprobiert, um die Geschwindigkeit zu beschleunigen, aber nichts hat funktioniert ...

Wir werden uns demnächst darauf konzentrieren. Wir sind im Moment ein wenig mit der Arbeit an Scherz überhäuft, aber wir sind entschlossen, es noch großartiger zu machen.

Gibt es Aufgaben, bei denen die Community helfen könnte?

+1

Die größte Hilfe wäre im Moment tatsächlich die Verbesserung der Dokumentation, der Website und das Durcharbeiten von Problemen und die Unterstützung von Leuten in Open Source.

Um unsere JEST-Tests in der Build-Pipeline zu beschleunigen, haben wir unsere Single-Core-Maschine durch eine Multi-Core-Maschine ersetzt. Jest erzeugt standardmäßig so viele Worker, wie Hardware-Threads verfügbar sind. Wenn Ihnen dies nicht zur Verfügung steht, können Sie manuell mit '-w' (maxWorkers) spielen. Sie können auch auf einem einzelnen Kern eine Beschleunigung erzielen.

Letztendlich haben wir festgestellt, dass das Mocking von Modulen sehr kostspielig ist (siehe meinen Kommentar oben) und einen Großteil der Ausführungszeit verursacht.

Scherz mit es6 ist für mich komplett unbrauchbar. Es dauert 10+ Sekunden, nur um zu starten, und dann dauert es 2 Sekunden, um den einzelnen Test auszuführen, den ich im Moment habe. Ich hatte viel mehr erwartet, zurück zum Karma zu wechseln :(

Wir arbeiten derzeit daran, node-haste durch einen neuen Modulresolver zu ersetzen, der dieses Problem beheben sollte.

Hallo zusammen. Gibt es Neuigkeiten zu diesem Thema?

Hallo, ist Jest für Nicht-React-Tests geeignet? Möchte in unserem Team einen gemeinsamen Standard für sowohl reagierende als auch nicht reagierende Apps haben.

Jest ist ein universeller Testläufer und Sie müssen React in keiner Weise verwenden. :) Schaut euch einfach eines der Beispiele an!

Hallo zusammen, einige wirklich interessante Informationen hier. Ich habe auch Probleme mit langsamen Tests. Ich habe derzeit 13 Tests, die ~ 15 Sekunden dauern.

Ich habe festgestellt, dass das Hinzufügen von "testPathDirs": ["<rootDir>/path/to/tests/"] zu unserer package.json-Datei dazu beigetragen hat, die Startzeit erheblich zu verbessern.

@cpojer Hast du ein Update für uns bezüglich des neuen und verbesserten Modulresolvers? Ich hoffe wirklich, dass dies der Schlüssel dafür sein wird, dass die Tests viel schneller laufen

Diese Arbeit findet in #599 statt.

Dank @cpojer 😀
Ich freue mich auf das fertige Haste2

Die gleichen Tests mit Mokka liefen für mich in 44 ms, wobei der Scherz volle 6 Sekunden dauerte.

Ich brauchte ungefähr 15 Minuten, um meine ersten 6 Testdateien mit jest auf Mocha , jsdom und sinon umzustellen.

Gute Nachrichten an alle, ich fusioniere heute #599 und es sollte endlich den langsamen Start beseitigen.

Ok, das sollte in Jest 0.9 endlich behoben sein. Entschuldigung, dass das so lange gedauert hat, aber es gab etwas Clownerie in Jest :)

Unter https://github.com/facebook/react/pull/6052 erfahren Sie, wie die React-Tests selbst beschleunigt wurden. Wenn Sie diese Verbesserung ausprobieren möchten, lesen Sie die Kommentare in #599. Es ist derzeit als jest-cli@next markiert, um zu sehen, ob es irgendwelche Fehler gibt, auf die Leute in Open Source stoßen könnten. Ich schließe dieses Problem als gelöst.

npm install jest-cli@next wenn Sie diese neue Version ausführen möchten (statt jest@next @cpojer)

oh ja, ich mache immer diesen Fehler :) Ich habe meinen ursprünglichen Kommentar bearbeitet.

@cpojer nach dem Upgrade mit npm install jest-cli@next habe ich Probleme bei der Angabe von dontMock . Damit meine ich, vor dem Update (mit [email protected]) funktioniert diese Zeile ordnungsgemäß:

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

dann nach dem Update auf 0.9.0 führt der gleiche Aufruf dazu, dass das Modul verspottet wird

@steinbachr , das sollte wahrscheinlich in einem separaten Thema behandelt werden. Wäre toll, wenn du ein Repro zur Verfügung stellen könntest, habe dieses Problem bei FB noch nicht gesehen!

danke @cpojer , Problem hier erstellt