Jest: Jest ist auf allen Windows-Computern (Windows 10 und niedriger) dreimal langsamer.

Verwandte: # 6783

Startet es langsam oder auch im Uhrenmodus? Wenn Sie nur während des Startvorgangs versuchen können, watchman zu installieren, sollte dies hilfreich sein (https://facebook.github.io/watchman/docs/install.html).

Wenn es die Tests durchläuft, scheint es von da an in Ordnung zu sein (BEARBEITEN: Tatsächlich ist es auch langsamer, wenn Tests ausgeführt werden. Es durchläuft eins nach dem anderen mit einer Geschwindigkeit von 0,5 Sekunden, während sich die Norm wie 0,05 anfühlt
Sekunden pro Test)
Das Starten und / oder Starten von Scherztests ist jedoch langsam (ca. 4-6 Sekunden Verzögerung, 4-6x langsamer als bei Mac-Computern).

Ich werde es mit dem Wächter versuchen und mich bei Ihnen melden

Wenn Sie mit ndb das Startup profilieren und herausfinden könnten, was langsam ist, wäre das auch eine große Hilfe 🙂

Die Verzögerung ist auch bei installiertem Watchman noch langsam.
Ich habe einen Profiling-Test mit ndb durchgeführt, auf dem "jest --verbose" ausgeführt wird. Hier sind die Ergebnisse:

Screenshot der ersten 1,7 Sekunden:

Screenshot von 1,8 Sekunden bis 2,7 Sekunden

Eine .json-Datei und eine .heapsnapshot-Datei, die nach der Aufnahme auf der Registerkarte "Profil" in ndb gespeichert wurden:

profiling.zip

@pfftdammitchris was ist dein [genauer] Anwendungsfall, in dem du das langsame bemerkt hast?
(eine Datei oder mehrere Dateien)? (Uhrenmodus oder nein)? können Sie das Beispiel zur Verfügung stellen.
Für ein Problem mit dem Dateiüberwachungsmodus => Bitte lesen Sie meinen letzten Kommentar in: # 6783

Es ist sowohl für einzelne als auch für mehrere Dateien mit oder ohne Überwachungsmodus langsam. Fast jedes Mal, wenn ein Test ausgeführt wird, verzögert sich die Initialisierung der Tests um mehr als 3 Sekunden, und die Tests werden langsam nacheinander um 0,3 oder 0,4 oder 0,5 Sekunden ausgeführt, während andere Testläufer wie Mokka / Chai normalerweise nur ausgeführt werden jeweils als ob es sich wie jeweils 0,05 Sekunden anfühlt.

Ich verwende Scherz in Codesandbox und sie scheinen bei der Initialisierung / Ausführung von Tests sofort Scherz zu machen. Ich habe gesehen, wie meine Kollegen auf ihren Mac-Computern Scherz gemacht haben, und sie haben ihn sofort wie gewohnt ausgeführt. Soweit ich weiß, sind es nur Windows-Maschinen. Ich benutze eine Windows-Maschine bei der Arbeit und der Scherz hat dort das langsame Problem, und ich benutze auch eine Windows-Maschine zu Hause und das Problem geht hier weiter.

Ich habe --runInBand verwendet, aber es schien die Unit-Tests je nach Gefühl um weitere 0,2 Sekunden etwas weiter verlangsamt zu haben.

Klärung

Ich habe --runInBand verwendet, aber es schien die Unit-Tests je nach Gefühl um weitere 0,2 Sekunden etwas weiter verlangsamt zu haben.

=> hast du es mit v24 versucht? Von Version 23 auf Version 24 sehen Sie NUR für dieses Szenario eine gute Verbesserung:
_auf dem rerun mit watch und nur wenn Sie gegen eine Datei laufen (nicht beim ersten Lauf) _
-> 2 / 3sec fallen auf 0,4 / 0,5sec.
Aber im Vergleich zu Mac habe ich es nie versucht ... also ist es vielleicht immer noch schlecht ... trotz der aktuellen Verbesserung

@SimenB

1. Ich betrachte https://github.com/facebook/jest/issues/7110 als Scherzgeschwindigkeitsregressionen [v22 vs v23] unter Windows für ALLE problematischen Szenarien.
   wo # 6783 ist einer von ihnen

2. Ich kann dieses Problem als: Geschwindigkeitsproblem für Scherz [Mac vs Windows] für ALLE problematischen Szenarien betrachten.

Hallo alle !
Ich kumuliere die Langsamkeit von Scherz 24 und Windows 10 (800er für 400 Tests!). Der schnellere Weg, dies alles zu beschleunigen, ist die Verwendung von wsl anstelle von Powershell oder cmd. Jetzt dauern meine Tests "nur" 189s.

Wir haben eine Reihe von 144 Testdateien mit 1302 Tests, deren Ausführung auf einem Windows 10 Build 15063-Computer, Core i7 mit 16 GB, 1 Minute und 43 Sekunden dauert, und auf einem MAC OS Mojave mit 32 GB 28 Sekunden. Unser Entwicklungsteam ist gleichmäßig zwischen Windows und Mac aufgeteilt und die Zahlen sind sehr wiederholbar.

Hier ist ein einfacher Test -

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

Ich habe es in Codesandbox abgelegt und es läuft ziemlich sofort - https://codesandbox.io/s/4q8l0q52lw

auf meinem Windows-Computer dauert es allerdings 4-5 Sekunden -

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

Testsuiten: 1 bestanden, 1 insgesamt
Tests: 1 bestanden, 1 insgesamt
Schnappschüsse: 0 insgesamt
Zeit: 4,158 s
Lief alle Testsuiten.

Der Test selbst dauerte 62 ms, der Rest des Testgurtes dauerte 4 Sekunden. Das Ausführen des Tests durch Drücken der Eingabetaste dauert genauso lange.

Meine Einstellungen -

> 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

Ich habe es mit der WSL Ubuntu versucht und die gleichen Ergebnisse (4-5 Sekunden) erhalten - diese Einstellungen -

  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

Ich fange gerade erst mit Jest an, habe also ziemlich einfache Tests und die Ausführung kann 15 bis 20 Sekunden dauern. Ich würde sie gerne schnell laufen lassen - sonst neige ich dazu, meinen Gedankengang zu verlieren!

@bburns lesen oben Ausgabe

@ Kensherman
Kannst du es mit Micromatch 4 in deinen Garnauflösungen versuchen? um zu sehen, ob es in Windows besser ist, bitte?
https://github.com/facebook/jest/issues/7963#issuecomment -483985345

Ich bin auf einem brandneuen MacBook Pro. Da ich Schüler unter MacOS und Windows 10 habe, habe ich beschlossen, meinem Laufwerk zwei weitere Partitionen hinzuzufügen. eine für Windows 10 und eine für gemeinsam genutzten Speicher mit Tuxera NTFS.

Ich bin heute auf dieses Geschwindigkeitsproblem gestoßen, als ich eine JavaScript-Lektion vorbereitet habe, die Komponententests enthält. Ich führe Jest tatsächlich unter MacOS aus, aber der Code und die Tests befinden sich auf der gemeinsam genutzten NTFS-Partition. Selbst wenn alle Suiten als describe.skip markiert sind, dauert die Fertigstellung von Jest mehr als 10 Sekunden, sowohl im Single-Run- als auch im Watch-Modus.

8 Suiten
42 Tests

Ich habe jest gegen mocha und chai getauscht und die Läufe wurden wieder auf den 1-Sekunden-Single- und 10-Millisekunden-Watch-Modus reduziert.

Ich tauschte den Scherz gegen Mokka und Chai und die Läufe gingen zurück auf etwa 1 Sekunde Single- und 10 Millisekunden-Uhrmodus.

Grundsätzlich hast du meinen letzten Beitrag nicht gelesen. Sie wollten mocha/chai fördern ... wir alle wissen davon ... Wir versuchen, die Regression des Scherzes zu korrigieren. Entweder helfen Sie dabei [aus meinem Beitrag] ...can you try with micromatch 4... oder Sie halten diese nutzlosen Kommentare aus dem Thread heraus. Es tut mir leid, direkt zu sein, aber irgendwann gibt es keine andere Möglichkeit, es auszudrücken.

@nasreddineskandrani Ich probiere [email protected] aus, aber ich kann immer noch eine extrem langsame Ausführung sehen, wenn ich im

@pachumon das

Sie müssen eine Abhängigkeit von Jest von einer bestimmten Version festlegen, um das Leistungsproblem zu beseitigen (theoretisch). Das Update wird standardmäßig in Jest 25 vorhanden sein.> Lesen Sie hier, um zu erfahren, wie ein Entwickler dies herausfindet. https://github.com/ facebook / jest / issue / 7963 # issuecomment -483985345

Um die Abhängigkeit (Micromatch) auf die Version zu setzen, in der das Update durchgeführt wurde => Sie können hier überprüfen, ob ich ein Beispiel in einem kleinen Projekt gemacht habe
https://github.com/nasreddineskandrani/benchmark_jest/blob/master/jest_24_with_micromatch4/package.json

Fügen Sie zu Ihrem package.json : (muss yarn nicht npm )

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

Hoffe das hilft! und auf Feedback warten

Meine Testlaufzeit ist ebenfalls von ~ 2,5 Minuten am 23.6.0 auf ~ 15 Minuten am 24.7.1 und 24.8.0 gestiegen. Auf unserem CI-Server wird Windows ausgeführt und die Erstellungszeit hat sich mit diesem Upgrade ähnlich stark erhöht. Ich habe versucht, die oben von @nasreddineskandrani erwähnte Überschreibung der Auflösung von Mikromatch-Abhängigkeiten ohne Erfolg

@ TomMahle das ist ein super schlechtes newz :( (die Regression, über die wir oben sprechen, war bereits in 23.6)
Im Moment zeigte ein einfaches 'Beispiel'-Projekt eine gute Leistung. nach dem Micromatch-Update.
Wir brauchen also ein wirklich problematisches Projekt zum Debuggen. Ist Ihr Projekt privat? oder öffentlich?

Vielen Dank für den Vorschlag zu micromatch @nasreddineskandrani , aber wie bei @TomMahle oben schien es auch für mich keine Verbesserung der Leistung zu sein, ihn auf ^4.0.0 fixieren . 😢

Ich habe jedoch eine funky Sache herausgefunden, die bei der Diagnose dieses Problems helfen könnte.

Ich kann Jest entweder auf meinem nativen Windows-System in einem Docker-Container ausführen, in dem das Haupt-App-Verzeichnis von meinem Windows-Dateisystem bereitgestellt wird. Das Ausführen im Nicht- Überwachungsmodus scheint auf beiden Systemen ein nahezu identisches Verhalten zu haben, was möglicherweise darauf hindeutet, dass das Kernproblem, wie

Im Überwachungsmodus sieht es jedoch etwas anders aus: native Fenster funktionieren immer langsam wie erwartet, aber der Docker-Container führt Tests nur beim ersten Durchlauf langsam p und Eingeben eines Musters), werden die Tests in weniger als einer Sekunde ausgeführt (dasselbe dauert in nativen Fenstern 3-4 Sekunden). Der einzige Nachteil bei der Verwendung von Docker ist, dass sich die Dateiänderungsereignisse nicht von meinem Windows-Volume auf Docker zu übertragen scheinen. Daher muss ich die Eingabetaste manuell drücken, um den Test erneut auszuführen, anstatt dass der Scherz ihn automatisch ausführt, aber ich denke, das ist es nicht relevant für das vorliegende Problem.

@nasreddineskandrani. Leider ist mein Projekt privat. Wenn es kleinere Codebeispiele gibt (die Scherzkonfiguration?) Oder Statistiken, die ich bereitstellen könnte, mache ich das gerne. Alle Tests scheinen dramatisch langsamer zu sein (nur unter Windows), daher glaube ich nicht, dass dies mit den spezifischen Tests zu tun hat.

Ich beende ein Docker-Zeug, das ich für meine persönlichen Websites mache -> nachdem (in einer Woche) ich darauf zurückkommen werde.

@ TomMahle
Ich werde meine Seite versuchen, einen Repo-Github mit dem von Ihnen beschriebenen Problem zu haben.

1. Wie viele Tests haben Sie?
2. Aktivieren Sie den dom -Modus für die Tests?
3. es ist reagieren oder eckig?
   Bonus:
4. Können Sie versuchen, das Problem in einem Github-Repo zu reproduzieren, um es debuggen zu können?
   Sie können meine teilen :
   Oder
5. Vielleicht mein Repo auf Ihrem Testgerät ausprobieren? und die Ergebnisse sehen? zwischen 23.6 und 24

Ich dachte, den Betreuern von micromatch wurde genug Aufmerksamkeit geschenkt, so dass dies bereits ausgebügelt worden sein muss. Das Ausführen (also Schreiben) von Scherztests unter Windows ist im Moment eine sehr unangenehme Erfahrung.

Ich bin seitdem zu Mokka / Chai gewechselt, aber ich bin überrascht, dass an diesem Problem noch gearbeitet wird.

Klärung

Ich habe --runInBand verwendet, aber es schien die Unit-Tests je nach Gefühl um weitere 0,2 Sekunden etwas weiter verlangsamt zu haben.

=> hast du es mit v24 versucht? Von Version 23 auf Version 24 sehen Sie NUR für dieses Szenario eine gute Verbesserung:
_auf dem rerun mit watch und nur wenn Sie gegen eine Datei laufen (nicht beim ersten Lauf) _
-> 2 / 3sec fallen auf 0,4 / 0,5sec.
Aber im Vergleich zu Mac habe ich es nie versucht ... also ist es vielleicht immer noch schlecht ... trotz der aktuellen Verbesserung

@SimenB

1. Ich betrachte # 7110 als Scherzgeschwindigkeitsregression [v22 vs v23] unter Windows für ALLE problematischen Szenarien.
   wo # 6783 ist einer von ihnen

2. Ich kann dieses Problem als: Geschwindigkeitsproblem für Scherz [Mac vs Windows] für ALLE problematischen Szenarien betrachten.

Ich habe es zu diesem Zeitpunkt mit beiden Versionen versucht.

Ich habe gerade ein neues Projekt mit einem Test mit einfachen Array-Push-Tests erstellt und es dauerte mehr als 10 Sekunden vom Start bis zur Fertigstellung. Das Projekt verwendet React / Typoskript, aber die Testdatei ist keine React-Komponentendatei, sondern eine normale Datei wie eine .js. Gif unten als visuelle Referenz, wenn es besser ist, das Problem zu visualisieren:

Beim ersten Ausführen des Tests ist mir aufgefallen, dass der Test auf 9 Sekunden geschätzt wird. Sobald sie abgeschlossen ist , versucht er zufällig die ein zweites Mal zum Abschluss testet.

Als ich das GIF-Bild oben aufgenommen habe (diesmal zum zweiten Mal), hat sich die geschätzte Zeit etwas verkürzt und es wurde kein zweiter Versuch durchgeführt. Ich bin mir nicht sicher, ob dies das erwartete Scherzverhalten ist.

Hier ist ein GIF von mir, wie ich Micromatch 4 mit Garn in einem separaten Projekt ausführe:

Unter Windows 10 und meinen Computerspezifikationen sind:
AMD FX (tm) -8320 Achtkernprozessor 3,50 GHz
16 GB RAM
x64
SSD

Lassen Sie mich hier mein Profiling teilen.
Technische Daten:

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

Schritte:

1. npx create-react-app my-app --typescript
2. ändere App.test.tsx
3. Führen Sie npm test

CPU-Profil:

CPU-20190801T141211.zip

Wird erwartet, dass 15 Sekunden nur mit der Anforderung von Modulen für eine einzelne triviale React-Komponente und einen Test verbracht werden?

Kann jemand mit mehr Erfahrung in der CPU-Profilerstellung einen Blick darauf werfen?

112 Tests
Fenster 10
erster Lauf 507 Sekunden
zweiter Lauf 23 Sekunden
Linux-Subsystem
erster Lauf 54 Sekunden
zweiter Lauf 29 Sekunden

85 Tests
Fenster 10
erster Lauf 44 Sekunden
zweiter Lauf 15 Sekunden
Linux-Subsystem
erster Lauf 26 Sekunden
zweiter Lauf 15 Sekunden

Kepro diese Ergebnisse sind mit Micromatch 4?

Ich bevorzuge direkten Chat als 1 Million Nachrichten hier zu haben. Es wird wirklich zur Hölle, alle Probleme zu verfolgen, die mit demselben Thema zusammenhängen.
Sie können hier beitreten. https://gitter.im/wearefrontend/jest-slow-windows
Ich bin jetzt dabei ...

Gitter ist über mein Firmen-VPN blockiert - wenn Sie nette Leute hier sinnvolle Updates posten könnten, wäre das erstaunlich <3

Sie können immer noch zu Hause eine Verbindung herstellen, um Open Source: P auszuführen und dies zu überprüfen
ps ein dota-spiel braucht mehr zeit zum anstehen jetzt kannst du gitter in dieser zeit überprüfen;)
Hier ist es jetzt: nodejs / node # 28946

@nasreddineskandrani Du hast mich. Ich habe ein neues MacBook bestellt, daher ist es bis zum Eintreffen nicht mehr als Open Source verfügbar. Ich weigere mich, in meiner Freizeit tatsächlich an meiner beschissenen Windows-Box zu arbeiten: D.

Es scheint, dass das Problem in den Knoten- / C ++ - Bereich übergegangen ist, der etwas (extrem) außerhalb meiner Komfortzone liegt - aber ich werde ein bisschen graben!

Hallo Neuigkeiten dazu?

Als Problemumgehung können Sie --runInBand verwenden, wenn Sie mehrere Tests starten. Es wird noch lange dauern, bis der erste Test gestartet ist, aber die nächsten Tests werden schnell sein.

Mein Projekt dauerte 21.803 Sekunden, um alle Tests auszuführen.
Jetzt mit --runInBand dauert es nur noch 7.412s

--runInBand macht es für mich nur noch langsamer. 1200tests. Ohne runinBand 70/50 Sekunden. Mit --runInBand laufen seine 90 Sekunden auf dem zweiten Platz bestenfalls
Unter Linux ist es 5-8x schneller

Versuchen Sie dann --maxWorkers = 4.

@ cino893 , keine Lösung :) versuchen, keine Lösung zu finden

Irgendwelche Neuigkeiten dazu? Ich habe wegen dieses Fehlers auf Version 21 gestapelt. v22 ist langsam und v23 ist noch langsamer.
Glaubt ihr nicht, dass es ein Fehler mit hoher Priorität ist?

Wo ich arbeite, haben wir keine Freiheit, das Betriebssystem auszuwählen oder Ubuntu unter Windows oder ähnlichem zu installieren.

@gombek hast du v25 ausprobiert? Das Jest-Team hat auf ganzer Linie viele Leistungsverbesserungen vorgenommen.

Hallo, ich dachte nur, ich würde dieser Diskussion einige zusätzliche Informationen hinzufügen. Jest ist auch sehr langsam, wenn er in einem Docker-Container ausgeführt wird, in dem der Quellcode und die Tests über das Volume vom Hostsystem (Windows) gemeinsam genutzt werden.

Ich bin mir ziemlich sicher, dass diese Verlangsamung auf die Unterschiede im Umgang von Windows mit Dateihandles im Vergleich zu Unix-Systemen zurückzuführen ist. Unter Unix, wenn für einen Prozess ein Dateihandle geöffnet ist, das andere Prozesse nicht daran hindert, diese Datei zu lesen. In Windows besitzt ein Prozess, der ein Dateihandle enthält, diese Datei, solange er das Handle freigibt. Ich würde mich mit Jest-Code für die Logik zum Lesen von Dateien befassen und insbesondere, wann und wie Dateihandles freigegeben werden. Ein sich gut benehmendes Programm sollte ohnehin Dateihandles sofort freigeben, nachdem es seine Arbeit erledigt hat. Testläufer wie Jest sollten ohnehin keinen Grund haben, das Dateihandle lange zu halten.

@gombek hast du v25 ausprobiert? Das Jest-Team hat auf ganzer Linie viele Leistungsverbesserungen vorgenommen.

Ich verwende Jest v25 unter Windows und es ist immer noch langsam

@pfftdammitchris Ich habe ziemlich komplexe

JEDOCH...

Besonders unter Windows sind aufdringliche Programme auf Kernel-Ebene wie Antivirenprogramme / File-Watcher wie Carbon Black (oder andere Echtzeit-Software zur Dateiüberwachung) äußerst vorsichtig. Wenn so etwas läuft, können Sie beim Ausführen von Jest

Ich habe letztes Jahr für ein Unternehmen gearbeitet, bei dem dieselbe Testsuite auf einem Macbook Pro ~ 30 Sekunden und auf einem Windows-Laptop 20 Minuten dauerte, während diese Programme zum Beobachten von Dateien ausgeführt wurden.

Ich habe keine Ahnung warum, aber ich würde vermuten, dass es etwas mit Dateihandles zu tun hat und wie Jest einige der Dateisystem-APIs von node.js verwendet.

Ich habe nur ungefähr 20 Tests und ich habe gerade einige Timings mit jest --watch gemacht, sowohl beim ersten Lauf als auch beim Drücken der Eingabetaste, um sie erneut auszuführen.

Unter Windows dauerte es beide Male ungefähr 15 Sekunden, während es unter Linux für den ersten Lauf ungefähr 5,3 Sekunden und für nachfolgende Läufe 2,3 Sekunden waren.

Ich habe versucht, -t = "GARBAGE" zu verwenden, damit alle Tests übersprungen werden. Das Linux hat 1,5 Sekunden gedauert, aber Windows hat immer noch 13 Sekunden gebraucht. Es scheint mir also, dass es nicht die tatsächliche Ausführung der Tests ist, die die Zeit in Anspruch nimmt!

Beide Computer verwenden die neueste Version von Node und Jest, und Linux ist eine VM, die in Windows mit Hyper-V ausgeführt wird. Wenn also andere Dinge gleich sind, würde ich erwarten, dass Windows schneller ist.

Ich habe nur ungefähr 20 Tests und ich habe gerade einige Timings mit jest --watch gemacht, sowohl beim ersten Lauf als auch beim Drücken der Eingabetaste, um sie erneut auszuführen.

Unter Windows dauerte es beide Male ungefähr 15 Sekunden, während es unter Linux für den ersten Lauf ungefähr 5,3 Sekunden und für nachfolgende Läufe 2,3 Sekunden waren.

Ich habe versucht, -t = "GARBAGE" zu verwenden, damit alle Tests übersprungen werden. Das Linux hat 1,5 Sekunden gedauert, aber Windows hat immer noch 13 Sekunden gebraucht. Es scheint mir also, dass es nicht die tatsächliche Ausführung der Tests ist, die die Zeit in Anspruch nimmt!

Beide Computer verwenden die neueste Version von Node und Jest, und Linux ist eine VM, die in Windows mit Hyper-V ausgeführt wird. Wenn also andere Dinge gleich sind, würde ich erwarten, dass Windows schneller ist.

Ja. Und wenn Sie die Quellcodes von Windows auf die Linux-VM mounten und die Tests ausführen, werden sie genauso langsam wie unter Windows. Dies impliziert stark, dass das Problem in der Dateiverarbeitungslogik von Jest liegt, wie ich bereits erwähnt habe.

Ja. Und wenn Sie die Quellcodes von Windows auf die Linux-VM mounten und die Tests ausführen, werden sie genauso langsam wie unter Windows. Dies impliziert stark, dass das Problem in der Dateiverarbeitungslogik von Jest liegt, wie ich bereits erwähnt habe.

Ich habe festgestellt, dass die CPU während der Ausführung der Tests hoch ist, die Festplattennutzung jedoch nicht. Da es sich um das Blockieren von Dateihandles handelte, würde ich erwarten, dass die CPU niedrig ist (es sei denn, der Scherz befindet sich irgendwie in einer engen Schleife und wartet darauf, dass die Handles freigegeben werden).

Ich habe die Kommentare von hevans90 zu Datei-Beobachtern gesehen. Ich habe kein Antivirenprogramm von Drittanbietern oder ähnliches installiert, aber das Deaktivieren des in Windows integrierten Echtzeitschutzes machte keinen merklichen Unterschied.

Ich hoffe, dies hilft jedem, der die Zeit hat, es zu versuchen und zu debuggen.

Daher habe ich heute bestätigt, dass Windows Defender einen großen Unterschied macht.
Früher hatte ich einige Ausschlüsse, aber als ich meinen neueren, schnelleren Laptop erhielt, konnte ich für mein ganzes Leben nicht herausfinden, warum der Scherz> 10 Minuten dauerte, um eine einzelne Datei auszuführen.

Dann erinnerte ich mich an Ausschlüsse.
Ich kann nicht genau sagen, welche Ausschlüsse einen Unterschied machen, aber ich habe den Läufer dazu gebracht, auf <15 Sekunden anstatt> 10 Minuten zu sinken

Ich fand einen Kern mit relevanten Ausschlüssen (wenn auch kraftvoll)
https://gist.github.com/darvell/edbc758b11ea4dcd7226b7c9f1821196
Ich habe auch Dateierweiterungen .ts .js .spec.ts .spec.js .tsx hinzugefügt

Ich kann nicht genau sagen, welche Ausschlüsse einen Unterschied machen, aber ich habe den Läufer dazu gebracht, auf <15 Sekunden anstatt> 10 Minuten zu sinken

hmm ich habe das gerade versucht und es schien keinen Unterschied für mich zu machen (wohlgemerkt, meins hat keine Minuten gedauert, also haben wir vielleicht verschiedene Probleme)

Ich habe sowieso immer Ausschlüsse. Und tatsächlich schlägt IntelliJ Idea automatisch vor, das Arbeitsbereichsverzeichnis in Ausschlüsse zu setzen, und erledigt dies für Sie, wenn Sie es zulassen (sollten Sie). In meinem Fall ist Langsamkeit also nicht auf Windows Defender oder einen anderen Virenscanner zurückzuführen.

Der Leistungsunterschied beträgt 5-10x im Vergleich zu einem Mac. PC ist eine leistungsstarke Desktop-Maschine (lesen Sie: viel schneller als das MacBook). Alles andere ist blitzschnell, nur Jest leidet unter diesem Problem.

irgendwelche Updates dazu? ... ich erlebe das Gleiche, jeder Test dauert lange, bis er eingerichtet und geladen ist, aber nachdem der erste geladen wurde, läuft er mit normaler Geschwindigkeit .....

Auch mit diesem Problem. Eine einzelne Testdatei mit einem einzelnen Hallo-Welt-Test. Der Start dauert ca. 15 Sekunden und der Test 12 Sekunden.

👋 Ich sehe einige Antworten, die darauf hinweisen, dass sie Typoskript mit Scherz verwenden - dies könnte einen Blick wert sein (wenn Sie auch ts-jest verwenden): https://github.com/kulshekhar/ts-jest/issues/ 908 # issuecomment -484043250

Die Änderung für mich bestand darin, 30 Minuten auf einen Scherz (ohne Cache) zu warten, um nur wenige Sekunden zu beginnen.

Beachten Sie, dass das Setzen des Flags "isoliertes Modul" zu keiner Typprüfung Ihrer Spezifikationsdateien (und zum Verlust einiger Funktionen) führt: https://github.com/kulshekhar/ts-jest/blob/master/docs/user/ config / isolationModules.md

Ich poste dies nur hier, da es nützlich sein kann, festzustellen, ob Ihr Problem im Scherz liegt.

👋 Ich sehe einige Antworten, die darauf hinweisen, dass sie Typoskript mit Scherz verwenden - dies könnte einen Blick wert sein (wenn Sie auch ts-jest verwenden): kulshekhar / ts-jest # 908 (Kommentar)

Die Änderung für mich bestand darin, 30 Minuten auf einen Scherz (ohne Cache) zu warten, um nur wenige Sekunden zu beginnen.

Beachten Sie, dass das Setzen des Flags "isoliertes Modul" zu keiner Typprüfung Ihrer Spezifikationsdateien (und zum Verlust einiger Funktionen) führt: https://github.com/kulshekhar/ts-jest/blob/master/docs/user/ config / isolationModules.md

Ich poste dies nur hier, da es nützlich sein kann, festzustellen, ob Ihr Problem im Scherz liegt.

Reines JavaScript hier. Ich habe dieses Problem also nicht im Zusammenhang mit TypeScript.

Zu Ihrer Information: https://github.com/kulshekhar/ts-jest/pull/1549 wird in der Alpha-Version von ts-jest sein (möglicherweise heute). Jeder, der ts-jest verwendet, hilft beim Testen der Alpha-Version und gibt uns einige Rückmeldungen für https://github.com/kulshekhar/ts-jest/issues/1115

Auch mit diesem Problem. Eine einzelne Testdatei mit einem einzelnen Hallo-Welt-Test. Der Start dauert ca. 15 Sekunden und der Test 12 Sekunden.

Habe gerade den gleichen Test auf einem Mac ausgeführt. Der Start dauert ca. 1,5 Sekunden, der Test <1 Sekunde.

Auch mit JS, hier nicht TS.

Auch hier reines JavaScript mit Jest. Ich habe einen leistungsstarken Quad-Core-Laptop mit Intel 10gen-Prozessoren und alles andere ist blitzschnell, aber [email protected] unter Windows 2-3 Mal 2-3 Mal mehr, um einige grundlegende Tests durchzuführen.

Gleiches Problem, ungefähr 60 Sekunden, damit meine Tests unter Windows ausgeführt werden können, und in den ersten 45 Sekunden wird keine Benutzeroberfläche angezeigt. Auf meinem Linux-Computer wurde genau dieselbe Testsuite ausgeführt, und es dauerte 8 Sekunden, bis sie vollständig ausgeführt wurde.

Der obige Kommentar von

@ryanrapini folgte dem Rat von @Cellule (ging aber die Windows UI > Virus and Threat Protection > Manage Settings > Add Exclusions ) und sah, dass einige Tests von 13 Sekunden auf 6 Sekunden gingen, also im Grunde die Hälfte. Vielen Dank!

Möchte jemand einen Abschnitt über Windows Defender (oder AV im Allgemeinen?) Auf der FAQ-Seite der Website verfassen? https://jestjs.io/docs/en/troubleshooter

Ich kann bestätigen, dass die Verwendung von isolatedModules: true mit ts-jest beim Kaltstart einen RIESIGEN Unterschied gemacht hat (~ 10 Minuten => 15 Sekunden).
Ich habe ihre Verbesserung im Alpha nicht getestet, weil ich darauf warte, dass # 9457 angesprochen wird, bevor ich auf Scherz 25 aktualisiere

Hallo zusammen,

Gleiches Problem hier und keine Lösung funktioniert bei mir ...

Ich führe einen sehr einfachen Code aus, für den ich derzeit einige Tests habe.
Es ist aus dem "Advanced React Course" von Wes Bo.
Er führt es auf einem Mac aus und erhält sofort eine Antwort von seinem Computer.

Und für mich:

Testsuiten: 2 übersprungen, 15 bestanden, 15 von insgesamt 17
Tests: 6 übersprungen, 37 bestanden, 43 insgesamt
Schnappschüsse: 18 bestanden, 18 insgesamt
Zeit: 5.869s
Lief alle Testsuiten.

isolatedModules: true ändert nichts an meinem Fall, ich bin immer noch ungefähr 5-6 Sekunden.
Und wenn ich mit einer beliebigen Option mit dem Testen beginne, dauert es 9 bis 10 Sekunden.

Das Hinzufügen meines Entwicklungsordners zu den Defender-Ausnahmen hat auch nichts bewirkt:

Testsuiten: 2 übersprungen, 15 bestanden, 15 von insgesamt 17
Tests: 6 übersprungen, 37 bestanden, 43 insgesamt
Schnappschüsse: 18 bestanden, 18 insgesamt
Zeit: 5,563 s
Lief alle Testsuiten.

Gibt es eine gute Option unter Windows?
Muss ich mich für wsl2 entscheiden?

Hallo zusammen,

Gleiches Problem hier und keine Lösung funktioniert bei mir ...

Ich führe einen sehr einfachen Code aus, für den ich derzeit einige Tests habe.
Es ist aus dem "Advanced React Course" von Wes Bo.
Er führt es auf einem Mac aus und erhält sofort eine Antwort von seinem Computer.

Und für mich:

Testsuiten: 2 übersprungen, 15 bestanden, 15 von insgesamt 17
Tests: 6 übersprungen, 37 bestanden, 43 insgesamt
Schnappschüsse: 18 bestanden, 18 insgesamt
Zeit: 5.869s
Lief alle Testsuiten.

isolatedModules: true ändert nichts an meinem Fall, ich bin immer noch ungefähr 5-6 Sekunden.
Und wenn ich mit einer beliebigen Option mit dem Testen beginne, dauert es 9 bis 10 Sekunden.

Das Hinzufügen meines Entwicklungsordners zu den Defender-Ausnahmen hat auch nichts bewirkt:

Testsuiten: 2 übersprungen, 15 bestanden, 15 von insgesamt 17
Tests: 6 übersprungen, 37 bestanden, 43 insgesamt
Schnappschüsse: 18 bestanden, 18 insgesamt
Zeit: 5,563 s
Lief alle Testsuiten.

Gibt es eine gute Option unter Windows?
Muss ich mich für wsl2 entscheiden?

Können Sie versuchen, meine Lösung anzuwenden und mir zu sagen, ob sie etwas bewirkt? (Eigentlich Cellules Lösung, aber ich habe es über das Menü gemacht, anstatt ein Skript auszuführen)

Können Sie versuchen, meine Lösung anzuwenden und mir zu sagen, ob sie etwas bewirkt? (Eigentlich Cellules Lösung, aber ich habe es über das Menü gemacht, anstatt ein Skript auszuführen)

Wie ich in meiner Nachricht sagte, habe ich das schon getan :)

Ich meine, ich habe verfolgt, was du getan hast, über das Menü und alles.

Ich habe dieses Problem auch unter Windows. Der Test selbst läuft in <1 Sekunde, aber die Ausführung des gesamten Setups dauert ca. 15 Sekunden. Ich habe es mit v24 und v26 versucht, es ist tatsächlich etwas langsamer auf v26

Ich hatte mit keinem der folgenden Dinge Glück (es hat die Ausführungszeit nicht verbessert):

• Hinzufügen von --runInBand
• Einstellen von maxWorkers
• Hinzufügen von .ts .js .spec.ts .spec.js .tsx Ausschlüssen zu Virus and Threat Protection , wie von @Cellule und @alessioalex vorgeschlagen

Gleiches Problem unter Windows hier mit Vanille-Javascript sowie einem neuen Typoskript-Projekt. 2 Sekunden, um 9 Unit-Tests durchzuführen, die mit Mokka in <10 ms ausgeführt werden.

Das ist verrückt!

Einfach Scherz global installiert und jetzt läuft genau das gleiche Projekt in 0,9s statt 52 (!!!) Sekunden!
npm remove jest im Projekt also
npm install -g jest

Natürlich möchte ich Jest als Dev-Abhängigkeit wieder in das Projekt integrieren. Irgendeine Idee, warum das passiert?

Das ist verrückt!

Einfach Scherz global installiert und jetzt läuft genau das gleiche Projekt in 0,9s statt 52 (!!!) Sekunden!
npm remove jest im Projekt also
npm install -g jest

Natürlich möchte ich Jest als Dev-Abhängigkeit wieder in das Projekt integrieren. Irgendeine Idee, warum das passiert?

Das klingt für mich definitiv nach einem Virenscanner-Problem. Das heißt, Ihr Projektverzeichnis befindet sich im Bereich des Virenscannings, wodurch der Scherz zu einem Crawl verlangsamt wird, Ihr globales npm-Verzeichnis jedoch nicht. Dies ist jedoch nur eine Vermutung.

Ich habe gerade das Gleiche wie @JPustkuchen versucht und die Leistung geht von ~ 10s auf <1 Sekunde.

Ich habe meinen Projektordner von Windows Defender ausgeschlossen, aber Jest läuft immer noch langsam.

Ich weiß nicht, ob daran noch gearbeitet wird, aber ich stelle fest, dass die Tests im Überwachungsmodus sofort fehlschlagen, wenn ich einen Tippfehler im Code mache. Was mich zu dem Gedanken führt, dass vor dem Kompilieren des Tests kein neuer Verzeichnis-Crawl erzwungen wird. Sehr einfache Tests dauern auch für mich 10 Sekunden.

Ich würde mir so sehr wünschen, dass jemand zumindest anerkennt, dass dies ein Problem ist. So wie es jetzt ist, ist mein Windows-Desktop-Computer, der viel Strom hat (lesen Sie: viel mehr als das Macbook meiner Kollegen), beim Ausführen von Tests ungefähr 69-mal langsamer als das MacBook! Dies zwingt mich praktisch dazu, den Frontend-Code nicht zu berühren, da es für mich so ineffizient ist, an diesen zu arbeiten, da Jest-Tests so langsam ablaufen. Wir müssen uns möglicherweise von Jest entfernen, wenn dies nicht behoben wird. Alles andere ist blitzschnell, aber Scherztests sind super langsam. Die Zeit wird für etwas anderes als die tatsächliche Ausführung der Tests aufgewendet. Wenn die eigentliche Testlogik ausgeführt wird, gehen diese sehr schnell.

Positiver möchte ich nur sagen, dass ich diesem Fehler eine große Dankbarkeit schulde. Es war der letzte Strohhalm, der mich dazu brachte, für meinen Hauptentwicklungsworkflow auf Linux umzusteigen, und ich war noch nie glücklicher. Ich kann nicht sagen, dass ich niemals zurückkehren würde, da ich manchmal an Legacy-Projekten arbeiten muss, aber da der ASP.NET-Kern plattformübergreifend ist, werden die Gründe für das Zurückfahren in Windows immer geringer.

Bitte @ timrobinson33 bleiben wir beim Thema. Es gibt keinen Grund, warum jest 68-mal langsamer sein sollte als jede andere Umgebung unter Windows, wenn man bedenkt, dass Node auf jeder Plattform einwandfrei funktioniert. Ich darf auch hinzufügen, dass ich dieses Problem bei keinem anderen Testläufer festgestellt habe.

Ich habe mit v26.4.2 in meinem Benchmark Jest Github Repo getestet.
https://github.com/nasreddineskandrani/benchmark_jest
Knotenversion auf meinem Computer: v12.13.0

ziemlich gut, wenn ich den einfachen Test aktualisiere (siehe Screenshot)! Für mich ist Scherz jetzt richtig für einen einfachen Test.
Wenn Sie ein Problem bei Ihrer Arbeit haben. Sie müssen versuchen, das Problem zu isolieren, da es standardmäßig in Ordnung ist.

@ Empperi kannst du mein Benchmark Repo ausprobieren. Beispiel mit dem Ordner v26 und sagen Sie mir, wie lange es dauert, diesen Test auf Ihrem Computer auszuführen? Wenn es nicht 0,166 ms oder mehr ist, haben Sie ein Problem auf Ihrer Seite.

Ich habe mit v26.4.2 in meinem Benchmark Jest Github Repo getestet.
https://github.com/nasreddineskandrani/benchmark_jest
Knotenversion auf meinem Computer: v12.13.0

ziemlich gut, wenn ich den einfachen Test aktualisiere (siehe Screenshot)! Für mich ist Scherz jetzt richtig für einen einfachen Test.
Wenn Sie ein Problem bei Ihrer Arbeit haben. Sie müssen versuchen, das Problem zu isolieren, da es standardmäßig in Ordnung ist.

@ Empperi kannst du mein Benchmark Repo ausprobieren. Beispiel mit dem Ordner v26 und sagen Sie mir, wie lange es dauert, diesen Test auf Ihrem Computer auszuführen? Wenn es nicht 0,166 ms oder mehr ist, haben Sie ein Problem auf Ihrer Seite.

Wie erwartet kein Unterschied zu Ihrer Test-Setup-Leistung. Läuft tatsächlich etwas schneller als auf Ihrem Computer. Ihr Test-Setup wurde so geändert, dass es 100 Testdateien unter __tests__ und auch diese laufen einwandfrei. Da unsere App react-scripts ich dies auch Ihrem Beispiel hinzugefügt, um zu überprüfen, ob dies das eigentliche Problem verursachen könnte, aber keinen Unterschied in der Leistung.

JEDOCH habe ich dann versucht, diese Tests in WSL2-Bash (gegen NTFS-Dateisystem) auszuführen und die Ausführungszeit fast 10x bis zur rohen Powershell zu boomen. Bei WSL2 ist eine langsamere E / A-Geschwindigkeit gegenüber NTFS zu erwarten, aber wenn man bedenkt, wie einfach dieses Setup ist (nur 100 Testdateien mit jeweils einem Test), sollte es wirklich nicht so viel bewirken. Als Referenz habe ich dies auf WSL2 Bash ausgeführt:

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

Das zeigt, dass das Lesen des Dateisystems von WSL2 praktisch keine Zeit in Anspruch nimmt. Als Referenz ähnlicher Befehl in 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

Was zeigt, dass die Leistung auf dem gleichen Stadion liegt.

Auf dieser Grundlage würde ich sagen, dass das Problem möglicherweise dadurch verursacht wird, wie Jest E / A verwendet, und dass dies die Leistung von WSL2 dramatisch beeinflusst. Wenn es um das Projekt geht, das mir Probleme bereitet, ist es keine einfache Aufgabe, aufgrund von Code- und Testproblemen (nicht von mir erledigt!) Keine Bash zu benötigen. Angesichts der Tatsache, dass WSL2 immer beliebter wird, würde ich sagen, dass dies ein echtes Problem ist, das untersucht werden sollte.

Hoffe das hilft.

:bearbeiten:

Aus Neugier habe ich unsere Testsuite mit --no-watch zu sehen, ob das Beobachten des Dateisystems über WSL2 die Dinge irgendwie beeinflusst. Die Antwort ist nein, es wirkt sich wirklich nicht so stark aus.

Das Ausführen des Benchmarks auf meinem Windows-Computer dauert ungefähr 1,6 Sekunden. Ich benutze keine WSL.
Ich verwende AVG Antivirus, habe jedoch Ausnahmen sowohl für das Repository als auch für die ausführbare Knotendatei hinzugefügt.
Meine Festplatte ist eine SSD.

Die Knotenversion ist v12.16.1

Das sofortige Aktualisieren des Tests löst den Datei-Watcher aus, aber die tatsächliche Zeit, die zum Ausführen dieses Updates benötigt wird, liegt zwischen 1 und 2,4 Sekunden.

Ich wollte testen, ob es um die Umgebung geht.

Ich habe mit diesem Repo rumgespielt: https://github.com/kentcdodds/react-testing-library-course/tree/tjs

• Ich gehe für npm test und alle Tests werden im Überwachungsmodus ausgeführt.
• Ich drücke 'p', um ein Muster für eine Datei einzugeben, und tippe "tdd-02" ein. Ich bekomme mehr als 3 Sekunden Ausführungszeit.
  

Es würde mich wundern, wenn Kent C. Dodds in seinem bezahlten Kurs eine durcheinandergebrachte Umgebung hat, aber wenn er dies tut, können Sie es dort wahrscheinlich debuggen :? In seinen Videos läuft es ganz gut, ich denke er benutzt einen Mac.

Ich muss etwas sehr Seltsames bemerken, das ich nicht wiedergeben kann - ich hatte einige aufeinanderfolgende Testwiederholungen, die für eine der Dateien (tdd-02 ... js) für ungefähr 0,1 s und für die Datei daneben ausgeführt wurden ( tdd-01 ... js) - ungefähr 3s. Der Code ist fast gleich und verwendet die gleichen Abhängigkeiten. Also habe ich den Code aus der schnell laufenden Datei kopiert und in die langsam laufende Datei eingefügt und umgekehrt. Die Ergebnisse waren die gleichen - die langsam laufende Datei blieb langsam und die schnell laufende Datei blieb schnell, wobei die tatsächlichen Codes ausgetauscht wurden. Das wird verrückt. Jetzt laufen beide Dateien wieder langsam (3-6s).

@Glinkis kannst du versuchen, nach dem ersten Lauf die Eingabetaste zu drücken? Wird es immer noch in 1,6 Sekunden angezeigt? (Wiederholung auslösen)

@SimeonRolev Ich werde einen Blick auf das Beispiel werfen, das Sie gepostet haben, und sehen, welche Art von Nummer ich mit den gleichen Schritten erhalte (Muster ...)
aktualisieren:
try1: Ich habe es als du versucht und habe 6 Sekunden bekommen, als ich deine Schritte ausprobiert habe -> bei erneuter Ausführung des gleichen Tests auf 3 Sekunden fallen (Enter drücken)
try2: Upgrade des Scherzes auf 26,4 in Kent Repo -> 3 Sek. Erster Lauf in der Nähe des gleichen für die Wiederholung
try3: Ich habe eine index.spec.js -Datei aus meinem Benchmark-Test-Repo genommen. und ich ließ es zu Kent Repo fallen. (Löschen aller anderen Testdateien) -> Überraschung 2,8 Sek. (GLEICHER JEST 26.4.2, GLEICHER COMPUTER, POWERSHELL, NODE_VERSION usw. ... wie mein Test gestern hier gepostet hat)

Ich verstehe diesen try3 immer noch nicht => ~ 3sec beim erneuten Ausführen in Kent Repo für meine Datei, aber in meinem Repo sinkt er bei erneutem Ausführen auf 0,300 Sekunden ( debuggt )
edit: Kent sollte derjenige sein, der dies überprüft: P.

Durch Drücken der Eingabetaste wird der Test in ca. 200 ms ausgeführt.

@nasreddineskandrani Hast du es umgekehrt versucht? Ich meine, die Tests vom langsamen Repo auf deine kopieren? Aber ich glaube nicht, dass das Problem mit dem Repo liegt, das ich gepostet habe. Wie wir deutlich sehen können, haben viele Menschen das gleiche Problem. Ich habe nur ein reproduzierbares Beispiel veröffentlicht.

@kentcdodds Wirst du noch einmal unser Held sein?

@SimeonRolev In meinem Benchmark sehe ich nicht das gleiche Problem wie in Kent Repo. Sie haben etwas in Kent Repo. das verursacht diesen langsamen => außerhalb davon ist der scherz schneller.

Dieses Github-Problem hängt mit Jest-Leistungsfenstern im Vergleich zu MacOS / Linux zusammen, da sie nicht die gleiche Leistung erreichten. Sie haben es nicht Klausel, denke ich. (es ist jetzt viel besser als vor 2 Jahren mit jest v23)

Hallo, ich habe hier das gleiche Problem. Ich habe eine Windows-Maschine und WSL. Ich habe meine Projektdateien in die WSL kopiert, um dieses Verhalten zu testen. Hier sind die Läufe derselben zwei grundlegenden Tests:
Windows 10 (Version 2004):

WSL 2 (Ubuntu 20.04):

Die Tests sind sehr einfach:

Das Projekt wird mit CRA erstellt, daher gibt es keine Konfiguration, um die Einstellungen zu verpfuschen. Ich habe nichts in Bezug auf Jest hinzugefügt.
Die gleichen Tests laufen auf Mokka fast augenblicklich rasant schnell. Ich versuche, eine Testumgebung für unser Projekt einzurichten, und ich würde Jest wirklich gerne verwenden, aber wenn ich mehr und mehr Tests hinzufüge, wird die Testsuite anscheinend immer langsamer. Jeder Test scheint 0,8 Sekunden hinzuzufügen, was lächerlich ist, da sie nichts tun. Bei der Testausführung unter Windows ist etwas durcheinander, und ich weiß nicht, was.
Das Problem war schlimmer, ein einzelner Test würde ungefähr 15 Sekunden dauern, aber als ich --runInBand und hinzufügte, schien sich die Situation ein wenig zu verbessern, aber ich denke, es ist immer noch nicht genug, wenn man bedenkt, dass der Mokka-Uhrmodus sofort ist.

Yarn ist Version 1.22.5, alle anderen npm-Abhängigkeiten (wie React und React-Skripte) sind aktuell.

Ich habe den Antiviren- und Windows Defender deaktiviert, um festzustellen, ob er Auswirkungen hat, aber nicht. Außerdem habe ich die Indizierung für meinen Projektordner deaktiviert, ohne Erfolg.

Bearbeiten: Ich habe versucht, die Eingabetaste zu drücken, und die Tests waren so schnell wie bei der WSL:

Jetzt bin ich wirklich verwirrt :)

Dies scheint jedoch immer noch sehr langsam zu sein, da anscheinend jeder Test 0,3 Sekunden dauert, was sehr viel ist, wenn man bedenkt, dass sie nichts tun. Ich erwarte, dass diese Suite in weniger als 0,1 Sekunden fertiggestellt sein wird.

Bearbeiten 2: Als ich meiner Testsuite 100 Tests hinzugefügt habe, dauerte es ungefähr 44 Sekunden, um sie auszuführen, selbst wenn ich die Eingabetaste drücke, um sie auszuführen:

Dieselben Testsuiten dauern in der WSL etwa 9-10 Sekunden: