Ich sehe genau das gleiche Problem. Tests werden bestanden und dann hängt Mokka einfach. Siehe mein Travis CI:
https://travis-ci.org/mkrufky/node-dvbtee/builds/282593109

Ich habe das gleiche Problem auch bei video-dev / hls.js bemerkt - Mokka hängt nur nach bestandener Prüfung:
https://travis-ci.org/video-dev/hls.js/builds/282590422

Habt ihr die Versionshinweise gelesen? https://boneskull.com/mocha-v4-nears-release/#mochawontforceexit

Vielen Dank. tok bad Die Mokka-Website wird mit dieser Änderung nicht aktualisiert. Die Cli Args dort erwähnen es nicht.

Abgesehen von der Bereitstellung einer schnellen Lösung (verwenden Sie --exit ) stimme ich zu, dass sie das Kernproblem beim Auffinden der fehlerhaften Tests dem Benutzer überlassen haben. Ich habe jetzt selbst Probleme damit, aber wenn ich Hauptversionen aktualisiere, achte ich darauf, die Versionshinweise zu lesen und nicht blind zu aktualisieren

In den Versionshinweisen wird empfohlen, why-is-node-running denn, dies funktioniert aufgrund von https://github.com/mafintosh/why-is-node-running/issues/7 nicht

Auch davon betroffen. Ich verstehe die Gründe für die Änderung der Standardeinstellung und danke Ihnen, dass Sie die Hauptversion erhöht haben. Angesichts der Tatsache, dass why-is-node-running aufgegeben und fehlerhaft ist, ist dies möglicherweise nicht die benutzerfreundlichste Änderung.

Hallo zusammen,

Zunächst möchte ich mich für den groben Upgrade-Pfad in diesem Punkt entschuldigen - wir sind uns definitiv einig, dass Mocha dem Benutzer mitteilen sollte, was die Tests am Laufen hält (und dann müsste er den Prozess nicht einmal offen halten; es könnte einfach sein ein Grund sein, Fehler zurückzugeben, nachdem sie fertig sind), aber noch keinen völlig zufriedenstellenden Weg gefunden haben, dies zu tun. Version 4 hatte nicht die Zeit, die wir in sie investieren wollten, da unser CI aufgrund von Änderungen im Installationsprogramm von PhantomJS 1.x fehlschlug (package-lock.json hätte dies wahrscheinlich verhindert, wenn wir dies getan hätten es wurde vorher eingerichtet, aber wir können es immer noch nicht zum Laufen bringen ). why-is-node-running war das einzige Tool, das wir als hilfreich empfunden haben, aber wir glauben nicht, dass wir es integrieren können (zwischen der Anforderung von --expose-internals und dem Fehlen einer guten Möglichkeit, die Ausgabe programmgesteuert abzurufen). Ich habe festgestellt, dass es funktioniert, wenn Sie ein paar Schritte befolgen:

• Führen Sie Mocha mit --expose-internals ( node --expose-internals node_modules/mocha/bin/_mocha ) aus.
• Stellen Sie sicher, dass Ihre erste Testdatei (z. B. in mocha.opts ) after(require('why-is-node-running')) enthält (oder zumindest damit beginnt)

... also ist es besser als nichts (obwohl ich sehen werde, ob ich die Versionshinweise aktualisieren kann, um dies genauer zu beschreiben), aber wenn jemand eine bessere Option kennt, lassen Sie es uns bitte wissen!

Es tut uns auch leid, dass die Site-Dokumentation fehlt - wir werden sie so schnell wie möglich aktualisieren. (Sobald # 2987 fertig ist, können wir es sogar zu einem automatischen Teil unserer Version / Publish Scripting machen!)

@ScottFreeCode

borisov<strong i="7">@glossy</strong>:~/test/mocha $ node --version
v6.11.3

borisov<strong i="8">@glossy</strong>:~/test/mocha $ ./node_modules/.bin/mocha --version
4.0.0

borisov<strong i="9">@glossy</strong>:~/test/mocha $ ./node_modules/.bin/mocha --expose-internals test.spec.js 
  error: unknown option `--expose-internals'

Bearbeiten:

Das funktioniert:

node --expose-internals ./node_modules/.bin/mocha test.spec.js

Richtig, tut mir leid, das war mir nicht klar - --expose-internals ist eine Knotenoption, die verwendet werden kann, indem node --expose-internals ./node_modules/mocha/bin/_mocha anstelle von ./node_modules/.bin/mocha . Das können wir auch beheben, da Mocha bestimmte Flags an Node weitergibt und wir diesen Flags --expose-internals hinzufügen können.

Erstellt mochajs / mochajs.github.io # 81 und # 3045, um die Aktualisierung der Dokumentation bzw. der Mocha-Node-Flags zu verfolgen. Wird dieses Problem mindestens bis zur Aktualisierung der Dokumentation offen halten.

@ScottFreeCode Vielleicht möchten Sie erwähnen, dass --expose-internals nur für Knoten <= 6 funktioniert. Hoffentlich können Benutzer vorübergehend auf Knoten 6 herunterstufen, um herauszufinden, welcher Timer abgebrochen oder nicht überprüft werden muss oder welche Sockets benötigt werden unref 'ed. Möglicherweise möchten Sie die Benutzer auch auf after und afterEach Hooks verweisen, um die Bereinigung durchzuführen.

(Gibt es einen globalen "After" -Hook, den Mokka aufruft, wenn alle Tests abgeschlossen sind?)

Auf jeden Fall schätze ich die Hilfe und danke für Mokka!

Vielleicht möchten Sie erwähnen, dass --expose-internals nur für den Knoten <= 6 funktioniert.

Bist du sicher? Ich habe mit Node 8.6.0 getestet. Obwohl nicht auf allen Betriebssystemen, sollte ich jede Box, die ich habe, starten und dreimal überprüfen ...

Hier ist ein Kern mit einer groben Anleitung, um dies vorerst zu umgehen.

Bist du sicher? Ich habe mit Node 8.6.0 getestet. Obwohl nicht auf allen Betriebssystemen, sollte ich jede Box, die ich habe, starten und dreimal überprüfen ...

Dies "funktioniert", indem es die Ausgabe des Moduls auslöst, aber es gibt mir nicht wirklich viele Informationen, unabhängig von der Version von Node.js.

Ich werde der Site einige Updates hinzufügen, aber bitte beachten Sie meine bevorstehenden Kommentare zu # 3045.

Dies "funktioniert", indem es die Ausgabe des Moduls auslöst, aber es gibt mir nicht wirklich viele Informationen, unabhängig von der Version von Node.js.

Es gibt einen nützlichen Stacktrace für setTimeout und setImmediate , aber überhaupt keine wirklichen Informationen für andere Dinge wie einen Listening-Server (wie ich erst kürzlich herausgefunden habe, als ich versucht habe zu verstehen, wie es funktioniert, was es ist tun). Das Beispiel "Async-Dump" im Kern hat einen echten Vorteil in Bezug auf die Arbeit für alles (und erfordert nicht --expose-internals ), obwohl es nur auf neueren Versionen von Node verwendet werden kann.

Ich nehme an, mein allgemeiner Rat wäre: "Wenn Sie sich die Haare ausreißen, fügen Sie einfach --exit und entspannen Sie sich." Dann benutze es nicht für dein nächstes Projekt: zwinker:

... und hier sind die Dokumente

Es tut uns leid, die geschlossene PR erneut zu kommentieren, aber hier gibt es möglicherweise eine benutzerfreundliche Lösung:

Man könnte eine Warnung über das geänderte Verhalten protokollieren, nachdem der Läufer ungefähr 3 Sekunden lang fertig war, aber der Prozess wurde nicht beendet.
Müsste nur ein setTimeout() hinzufügen, nachdem der Läufer fertig ist, und timeout.unref () aufrufen, um sicherzustellen, dass dieses Timeout den Prozess nicht am Beenden hindert. Wenn das Timeout ausgeführt wird, ist es Zeit für eine Warnung 😉

Ich habe darüber nachgedacht, aber ich bin besorgt, dass es andere Probleme mit Reportern oder anderen Integrationen verursachen wird ... Ich kann nicht beweisen, dass dies nicht der Fall ist.

Wenn Sie immer noch Probleme haben und why-is-node-running nicht richtig funktioniert, lesen Sie wtfnode .

Dieses Paket hat für mich viel besser funktioniert.

Ich kann sehen, dass es (gelinde gesagt) beunruhigend sein kann, wenn vorhandene Tests plötzlich nicht mehr beendet werden. Ich sehe eine Erwähnung über das neue Verhalten in den Versionshinweisen .

Ich habe die Änderung versehentlich selbst durch neue Tests entdeckt, die mich gezwungen haben, sicherzustellen, dass ich redis.quit () in einer after () -Funktion aufgerufen habe, und ich bin definitiv zufrieden mit dem neuen Verhalten, das mir richtig und angemessen erscheint.

Diesmal musste ich [diesen Kern] nicht verwenden, aber wie bereits von @boneskull erwähnt,

Ich muss zugeben, dass ich die Probleme in den Tickets, auf die verwiesen wird, die hinter dieser neuen Verhaltensänderung stehen, nicht ganz verstehe.

AFAICT, es hat etwas mit unbehandelten Promise-Ablehnungen zu tun. Aber entschuldigen Sie, wenn Sie ein Versprechen für einen Mokka-Test nicht lösen, wird Mokka diesen Test weder erfolgreich durchführen noch fortsetzen (wenn --bail ist), oder? Es muss sich also um ein schlecht implementiertes verschachteltes Versprechen handeln, das keinen Ablehnungshandler hat, aber der enthaltende Code muss trotzdem aufgelöst werden.

Wenn dies der Fall ist, sehe ich nicht, wie es Mochas Aufgabe ist, diese Probleme zu erkennen. Und wenn Sie etwas Magie implementieren, um diese Probleme zu erkennen, die dazu führen können, dass aktuelle (korrekt geschriebene) Tests auf unbestimmte Zeit hängen bleiben, sollte diese Magie ein Opt-In- Verhalten sein, kein Opt-Out - Verhalten - dh --no-exit statt --exit .

Ich schaue mir alle meine Tests mit dem offiziellen Node-Mongodb-nativen Treiber an, der hängt, weil dieser Treiber Verbindungen bündelt und sie nicht alle auf .close() schließt. Meine Tests verhalten sich ordnungsgemäß, eine Abhängigkeit jedoch nicht (oder doch? Ich weiß nicht unbedingt, dass es ein schlechtes Verhalten ist, verweilende Sockets oder Dateideskriptoren zu haben, bis ein Skript an einer anderen Stelle beendet wird - oder?). Was teste ich hier? Mein Code oder der eines anderen? Ich dachte, ich würde meine eigenen testen, aber anscheinend nicht.

Sicher, ich kann das --exit -Flag hinzufügen, aber der nächste Typ könnte es nicht, und so oder so scheint es einfach falsch, dass ich vollkommen feine Tests mit perfekt feinem Code schreiben kann, der getestet wird, und immer noch eine zufällige Abhängigkeitsursache habe meine Tests hängen auf unbestimmte Zeit.

Wenn ich ein process.exit() in einen letzten after() -Haken einfüge, hängen meine Tests nicht, aber dann bricht es schrecklich mit --watch (möglicherweise anderen Funktionen), nicht nur hindert mich daran, nach Änderungen zu suchen, wirft mich aber in eine cursorlose Hülle.

Es kann sehr gut sein, dass ich hier ahnungslos bin (sicherlich gibt es eine Menge, die ich nicht bekomme, und viele Leute waren involviert, also würde ich das eher glauben :)), ich fühle mich einfach so was ist nicht ganz ... richtig ...?

Prost :)

BEARBEITEN: Gibt es angesichts dieses Verhaltens eine Möglichkeit für mich, in einem Mokka-Test zu überprüfen, ob er mit --watch damit ich sicherstellen kann, dass ich nicht process.exit() und Dinge kaputt mache?

@DanielSmedegaardBuus TL; DR zur Lösung: --exit in die Datei mocha.opts . (Dies ist normalerweise die Lösung für alles, was beim Ausführen von Mocha immer festgelegt werden muss, als allgemeinerer Tipp.) Detailliertere Erläuterungen zu dieser Änderung: siehe unten.

In 2640 geht es um Ablehnungen von Versprechungen, es soll nichts anderes getan werden, als sie mit synchronen Ausnahmen in Einklang zu bringen, die aus asynchronem Testcode ohne Versprechungen ausgelöst werden, und es wurde noch nicht implementiert .

Hier geht es um Tests, bei denen Ressourcen, Listener oder laufende Arbeiten eingerichtet und nicht bereinigt werden, unabhängig davon, ob Versprechen in ihrer Implementierung und / oder im Test verwendet werden. Zum Beispiel:

Ich habe einen Test für eine API, die auf Websockets basiert und das Öffnen und Schließen von Verbindungen umfasst. Diese API war fehlerhaft und schloss die Verbindungen nicht richtig, bestand jedoch meine Tests, da die Tests nicht wirklich die Möglichkeit hatten, zu bestätigen, dass die zugrunde liegende Verbindung korrekt behandelt wurde. (Wenn ich nur meinen eigenen Code streng getestet hätte, hätte ich überprüfen können, ob die Abhängigkeit so verwendet wird, wie ich es fälschlicherweise für richtig gehalten habe. Ich habe jedoch mit dem realen Websocket genau getestet, um Probleme mit der Korrektheit der Verwendung zu erkennen. Integrationstests als Ergänzung zu den Komponententests.) Ich habe diesen Fehler festgestellt, als ich zum Verhalten von --no-exit (von Mocha 3; jetzt die Standardeinstellung in Mocha 4) gewechselt bin und festgestellt habe, dass der Knoten bei Ausführung dieser Tests nicht geschlossen wird, weil Die Websocket-Verbindung hört immer noch zu.

(Es ist wahr, dass der Fehler eher in einer Abhängigkeit als in Ihrem eigenen Code liegt, aber selbst dann kann es sinnvoll sein zu wissen, dass dies vor dem Versand mit einer bestimmten Version dieser Abhängigkeit der Fall ist - wie oben erwähnt in erster Linie besser für Integrationstests geeignet als für Komponententests, aber im Idealfall hat ein Projekt beides.)

Dies ist natürlich nicht immer notwendig - in einigen Fällen kann eine Ressource dieser Art so lange am Leben bleiben, bis der Prozess beendet ist, oder Node am Leben erhalten, obwohl keine andere Bereinigung der Ressource wirklich wichtig ist, oder könnte Teil eines Ressourcenpools sein, der einzelne Mitglieder wiederverwendet und den Pool nicht als Ganzes bereinigen muss - in solchen Fällen wäre --exit korrekt . Der Grund für die Änderung des Standardverhaltens bestand darin, die Sichtbarkeit solcher Probleme zu erhöhen: Früher würden Sie wahrscheinlich nie wissen, ob Sie --no-exit ausprobieren und nach solchen Fehlern suchen sollten. Jetzt werden Sie standardmäßig darauf stoßen und kann --exit wenn Sie feststellen, dass das Verhalten korrekt ist (oder zumindest keine Sorge wert ist).

Es gibt natürlich ein Problem mit dem "Fix", dass es nicht sehr informativ ist ,

Es tut mir leid, aber das war sehr frustrierend. Ich habe nur versucht herauszufinden, warum Mokka nicht austritt. https://boneskull.com/mocha-v4-nears-release/#mochawontforceexit verlinkt auf why-is-node-running . Jetzt habe ich versucht, dieses Modul zu verwenden. Es wurde die kryptische Meldung "Fehler: Modul kann nicht gefunden werden" angezeigt. internal / linkedlist '... (Stack Trace) ", und nachdem ich dem Kaninchenbau gefolgt bin, um herauszufinden, warum --expose-internals nicht funktioniert, lande ich unter https://github.com/mochajs/mocha/ Issues / 3045 , um eine vermeintliche Lösung zu finden, aber why-is-node-running sagt mir, dass es einen bekannten Handle gibt, der ihn offen hält, und ein paar unbekannte Handles, aber nichts auflistet.

Dies ist möglicherweise nicht der richtige Ort, um dies anzusprechen, aber Mokkas Dokumente sollten keine Lösungen empfehlen, die so viel googeln und Tauchen erfordern, um zur Arbeit zu kommen . Ich habe versucht, Dinge herauszunehmen und hinzuzufügen, mit sehr inkonsistentem Verhalten. Für zukünftige Benutzer und meine geistige Gesundheit:

package.json:

"scripts": {
    "test": "mocha --exit"
}

Das ist das Beste, was ich tun kann.

@jeffvandyke Ich verstehe Ihre Frustration und habe dieselben Probleme durchlaufen - aber wenn Sie irgendwelche Aussagen hinter Versprechungen haben, werden Sie diese Änderung vielleicht zu schätzen wissen.

Ich hatte eine Reihe von Spezifikationen, die ein flockiges asynchrones Verhalten hatten. Abhängig von der Ausführungsreihenfolge meiner Spezifikationen werden nicht erfasste Fehler bei der Ablehnung von Versprechungen in der Konsole protokolliert und dann von Hunderten anderer Tests, die bestanden wurden, außer Sichtweite gerollt, oder die Knoteninstanz wurde heruntergefahren, bevor die Ablehnung erfolgte.

Nach dem Entfernen von --exit aus meinem mocha.opts die abgelehnten Versprechen zuverlässig Fehler protokollieren und diese Fehler hervorheben.

Ich weiß, viele gemeinsame Schmerzen :) Mokkas dokumentiertes Verhalten klingt für mich tatsächlich korrekt, aber obwohl meine 5 Tests einfach genug erscheinen, nur mit Node-Fetch eine API zu testen, bin ich mir immer noch nicht sicher, warum Mokka nicht beendet wird. obwohl sie alle erfolgreich bestehen (ja, sie können auch scheitern). Ich könnte mehr Zeit damit verbringen, herauszufinden, warum why-is-node-running nicht funktioniert, aber ich bin es leid, über den Code anderer Leute nachzudenken, also denke ich, dass ich mir vorerst eine Pause gönnen werde.

Ich werde wahrscheinlich weiter damit spielen, und wenn ich etwas Reproduzierbares bekommen kann, könnte ich eine neue Ausgabe eröffnen, aber keine Versprechen.

Ich würde den Debugger des neuen Node Inspector empfehlen ... er hat gute asynchrone Traces.

Yay! Es stellt sich heraus, dass wtfnode viel besser result.text() oder .json() aufrufen muss oder die Verbindung offen bleibt. Wenn Sie wtfnode ./node_modules/.bin/_mocha ausführen und angezeigt .

Ich denke, es wäre einfacher gewesen, wenn die Dokumente dieses Paket empfohlen hätten, anstatt why-is-node-running .

Ein weiterer Vorschlag: Ich mag die Idee von wtfnode um aktive Handles aufzulisten, die den Knoten nach einiger Zeit am Leben erhalten.

Was auch immer das Richtige sein sollte, ich denke, es ist Müll, dass ich so weit schauen musste, um herauszufinden, warum Mokka nicht austreten würde. Wie auch immer, ich habe meine Vorschläge gegeben :)

Hallo Leute,
Ich denke, diese Funktion funktioniert möglicherweise immer noch nicht richtig. Dies ist der grundlegendste Test, den ich mir vorstellen kann, und Mokka kann immer noch nicht von selbst beendet werden. --no-exit ist eine ausgezeichnete Standardoption und ich bin alles dafür, aber entweder verstehe ich nicht, was ich falsch mache, oder etwas stimmt nicht mit Mokka und es verhindert, dass selbst die einfachsten Tests geschlossen werden.

describe('describe', function() { it('it', function(done) { done(); }); });

Zusammenfassung: --exit funktioniert, --no-exit schließt niemals einen Test ab.

In meinem Fall verwende ich eine Koa- Anwendung und teste mit Mocha 4 + Supertest .

Ich musste den Server zusammen mit dem Aufruf von done nach den Versionshinweisen "Um Fehlalarme zu vermeiden und bessere Testpraktiken zu fördern" schließen.

Vor:

request(app.listen())
  .post('/')
  .send(requestSrc)
  .expect({ f: {} }, done)

Nach:

const server = app.listen()

request(server)
  .post('/')
  .send(requestSrc)
  .expect({ f: {} }, () => {
    server.close()
    done()
  })

Hoffe es hilft Somenoe.

Ich mache vor jedem Test ein Bootstrapping für Mokka. Grundsätzlich wird ein kleiner HTTP-Server im selben Prozess gestartet.

Gibt es ein Ereignis, an das ich mich anschließen kann, um es herunterzufahren, nachdem Mocha nicht mehr läuft? Ich möchte es nur herunterfahren, aber gerade zu diesem Zeitpunkt.

Ich liebe die Idee hinter dieser Funktion übrigens. Es ist ein guter Test, um zu sehen, ob Sie baumelnde Ereignisse haben.

@evert Funktioniert es nicht, den Server in after ?

Gibt es ein globales "Nach allem", das läuft, nachdem Mokka fertig ist? Das habe ich vielleicht verpasst! Konnte es nicht in den Dokumenten finden.

Ja, es gibt einen globalen after Hook.

https://mochajs.org/#root -level-hooks

Vielen Dank! Ich habe das verpasst, sorry: Ich kannte die Begriffe, für die ich Strg-F drücken soll, nicht.

wtfnode hat bei mir nicht wirklich funktioniert. Ich konnte nur sehen, dass eine von Mokka gestartete PID hing.

Auf der anderen Seite funktionierte @boneskull gist: https://github.com/mochajs/mocha/issues/3044#issuecomment -351299745. Vielen Dank!

wtfnode muss gegen _mocha , nicht gegen mocha .

Danke für die --exit . Es hat es für mich behoben.

Geben Sie dieses Skript in package.json ein:
"Skripte": {
"test": "mokka --exit"
}}

Ich habe verschiedene in diesem Thread erwähnte Mittel ausprobiert:

• Warum-ist-Knoten-Laufen erzeugt keine Ausgabe
• wtfnode erzeugt eine Ausgabe, die jedoch nicht ausreicht, um festzustellen, wo die Dateideskriptoren / Sockets / Server / Timer im Code erstellt werden
• Fehler in der Debug-Methode von async_hooks
• Das Hinzufügen von –exit zum Mokka-cmd-Linienflag führt zum Beenden

Folgen Sie also

Dafür ist ein Debugger da, IMO. Wie würden Sie Ihre eigenen Skripte debuggen, wenn sie nie beendet würden?

https://github.com/GoogleChromeLabs/ndb ist ein cooles Projekt.

Off-Topic: Ich liebe dieses Ticket, nur für die Informationen zu Tools zur Fehlerbehebung, die es immer wieder gibt! :) :)

@borisovg Stellen
@boneskull Gibt es eine Debugger-Funktion " auflisten ", die mir nicht bekannt ist?

@mjgs es hat für mich getan - wtfnode funktioniert, aber nur, wenn ich es mit der _mocha Binärdatei verwendet habe, nicht mit der mocha one:

$ wtfnode ./node_modules/.bin/_mocha my-shitty-code.spec.js 


  tests
    ✓ some test


  1 passing (5ms)

^C[WTF Node?] open handles:
- File descriptors: (note: stdio always exists)
  - fd 1 (tty) (stdio)
  - fd 2 (tty) (stdio)
- Servers:
  - :::8080 (HTTP)
    - Listeners:
      - request: (anonymous) @ /home/borisov/test/my-shitty-code.js:4
- Intervals:
  - (5000 ~ 5 s) (anonymous) @ /home/borisov/test/my-shitty-code.js:8

@borisovg Danke für dein wirklich super Beispiel. In meinem Fall zeigt wtfnode, dass eine Mongo-Verbindung offen ist, aber alle Mongo-Verbindungen in meiner my-shitty-code.js wurden geschlossen, sodass das Problem von einem anderen Ort stammt und wtfnode nicht genügend Informationen darüber gibt, wo es sich befindet von.

Wenn wtfnode angibt, dass eine Mongo-Datenbankverbindung offen ist, ist sie offen. Warum würden Sie annehmen, dass es falsch ist?

@evert Ich denke, Sie haben vielleicht falsch interpretiert, was ich geschrieben habe

Minimale Beispiele eignen sich hervorragend zur Veranschaulichung, und es ist tatsächlich nützlich, eine ähnliche Ausgabe wie die angezeigten zu sehen, aber in echtem Code, der über viele Jahre geschrieben wurde, sind diese Verbindungen nicht so leicht zu finden. Es ist gut zu wissen, dass noch Mongo-Verbindungen offen sind, aber es ist nicht trivial, sie tatsächlich zu finden. Ich fand schließlich einige offene Verbindungen, aber sie waren viel tiefer im Code als die Oberflächenebene, auf der alle Verbindungen nachweislich geschlossen waren. WTfnode half nicht bei der Identifizierung, wo sie sich befanden, nur durch Auflisten des Mungo-Modulpfads. Ich habe noch einige zu finden, nur basierend auf der Portnummer, aber ich bin hoffnungsvoll.

Ich bin auf genau dieses Problem gestoßen, als ich eine Serverless-Funktion geschrieben habe, die mit Firebase kommuniziert. Es stellt sich heraus, dass das Admin-SDK ein offenes Handle auf unbestimmte Zeit beibehält. Aufgrund dieser Änderung (und des nachfolgenden Vorschlags, wtfnode , konnte ich diese Tatsache identifizieren und mir später eine Menge Kopfschmerzen (und Kosten) ersparen.

Meiner Meinung nach wäre es sehr hilfreich, eine Art "Wenn es X lange hängt und keine Ausgabe hat, wird Text in die Standardausgabe geworfen" -Logik aufzunehmen. Ich bin mir nicht sicher, wie machbar das ist oder wie viel Bandbreite zur Verfügung steht, um eine solche Verbesserung zu erzielen, aber ich denke, das könnte helfen, die anfängliche Frustration über "wtf geht mit meinem Mokka weiter!" Zu lindern.

var timers = sinon.useFakeTimers({
    now: new Date().getTime(),
    shouldAdvanceTime: true,
});

Wenn ich timers.restore(); vergesse, bleibt der Prozess für immer hängen.

Basierend auf der Dokumentation @pgilad, die hier gesendet wurde, gibt es für mich eine sauberere Lösung. Wie die Dokumentation sagt:

Um Fehlalarme zu vermeiden und bessere Testpraktiken zu fördern, wird sich Mocha nicht mehr automatisch über process.exit () selbst töten, wenn es der Meinung ist, dass es ausgeführt werden sollte.

Eine sauberere Lösung wäre dann, eine globale after -Funktion zu erstellen (eine after außerhalb einer describe -Funktion), die ich in einer separaten Datei wie exit-mocha.js empfehlen würde. exit-mocha wenn Sie so wollen. Der Rückruf, an den Sie gesendet werden, kann einen ordnungsgemäßen Knotenprozess erzwingen, der ohne Fehler beendet wird. Die Datei kann an mocha cli gesendet werden, als wäre es eine andere Testdatei (sie könnte ein --exit -Flag simulieren).

exit-mocha.js oder exit-mocha

after('Exit mocha gracefully after finishing all tests execution'. function () {
  // Exit node process
  process.exit();
});

Dann können Sie Mokka-Tests durchführen wie:

mocha exit-mocha test/**/*.spec.js

oder

mocha exit-mocha.js test/**/*.spec.js

Es ist wichtig, dass, wenn Sie Platzhalter für den Namen der Testdateien verwenden, wie ich es mit test/**/*.spec.js getan habe, der Name der Datei exit-mocha NICHT mit dem Platzhaltermuster übereinstimmt, andernfalls nicht Sie können es als "Flagge" verwenden

@ vctr90 Das ist eine großartige Lösung, obwohl Sie in Ihrem Beispiel einen Punkt haben, in dem Sie ein Komma haben sollten. Auch das Ganze kann auf Folgendes reduziert werden:

after('Exit mocha gracefully after finishing all tests execution', process.exit);

Gibt es eine Chance, dass sich ein Entwickler einmischt, warum das Hinzufügen zu Mocha jemandem weh tun würde (weil es eindeutig vielen Menschen helfen würde)?

@machineghost Ich mag das neue Verhalten aus 2 Gründen:

1. Fast keine andere Bibliothek wird beendet, nachdem sie ihre Arbeit erledigt hat. Wenn Sie beispielsweise einen Node TCP-Server schließen, wird nicht automatisch ein Exit ausgelöst. Auf diese Weise stimmt es mit anderen Bibliotheken überein.
2. Wenn der Knoten nicht beendet wird, bedeutet dies, dass noch Ereignisse darauf warten, gelöst zu werden. Es ist wahrscheinlich besser, Ihren Code zu verbessern, damit die Dinge nach jedem Test aufgeräumt werden. Es könnte auch darauf hindeuten, dass Speicherlecks vorliegen.

Wenn ich darauf stoße, ist dies ein Anreiz für mich, meinen Code zu bereinigen, damit es nicht passiert.

Ihre Sichtweise dazu könnte sein: "Ich kümmere mich nicht um Speicherlecks" oder "Dies ist es nicht wert, in meiner Anwendung behoben zu werden". Wenn Sie in dieser Kategorie sind, ist es am einfachsten, ein mocha.opts und --exit hinzuzufügen.

Mir scheint nur, dass es darum geht, mehr Lärm zu machen, nicht zu signalisieren: In den allermeisten Fällen wird die App von niemandem besser, weil Mocha am Ende hängt.

Wenn Mocha standardmäßig verwendet wird, sollte es standardmäßig beendet werden, wenn die Tests (und alle after / afterEach -Aufrufe) beendet sind. Wenn Sie dies nicht nur tun, um den Leuten zu sagen, "Hey, Ihre künstliche Testumgebung ist künstlich", kommt dies der Mehrheit (oder sogar einer anständigen Minderheit) der Benutzer nicht zugute.

Wenn Leute wirklich nicht geschlossene Verbindungen debuggen möchten , sollte dies der Fall sein, für den Sie eine Option bereitstellen. Aber ist es für den Rest der Zeit wirklich von Vorteil für die Benutzer der Bibliothek, alle anderen zu verwechseln mit (was bedeutet zu sagen) "Sie befinden sich in einer Testumgebung und eines von einer Milliarde möglichen Dingen ist offen"?

Anders ausgedrückt, wenn Sie 99% der Leute sagen wollen, die auf dieses Problem stoßen: "Verwenden Sie einfach --exit ", dann sollten --exit vielleicht keine spezielle Option sein, die Sie haben müssen bereitstellen ... Vielleicht sollte das Standardverhalten darin bestehen, 99% der Benutzerfälle zu bedienen (während den Benutzern natürlich immer noch die Option --tell-me-if-I-have-unclosed-stuff-in-my-testing-environment-and-that-is-actually-what-i-am-trying-to-find-out )?

Ich meine, wenn Sie das zur Option gemacht hätten, wie oft würden die Leute es Ihrer Meinung nach überhaupt passieren?

PS Ich bin gerade auf Folgendes gestoßen: https://stackoverflow.com/questions/54999115/where-to-destroy-knex-connection. Wenn Sie sich die zweite Antwort ansehen, hat dieses Verhalten in Mocha direkt dazu geführt, dass mindestens ein Benutzer (der nicht ich ist, und ich schwöre, ich kenne sie nicht: Ich habe dies nur durch Glück gefunden, nachdem ich meinen letzten Beitrag verfasst habe) falsch hinzugefügt hat Nicht-Test- Code (diese "Funktion" ließ sie fälschlicherweise denken, dass sie knex.destroy() in ihrer App aufrufen müssen).

Zusammenfassende Version:

Nette Person: Wahrscheinlich müssen Sie knex.destroy () normalerweise nicht explizit aufrufen - dies wird durch die Dokumentation selbst impliziert (Hervorhebung von mir):

Nette Person: zitiert Dokumente

Verwirrte Person: Wenn ich knex.destroy () nicht aufrufe, bleibt mein Skript hängen. Was bedeutet es dann, dass wir knex.destroy () nicht explizit aufrufen müssen?

Nette Person: Ah, Sie haben nur an anderer Stelle erwähnt, dass dies für Mokka ist. Für reguläre Servernutzungen müssen Sie den Verbindungspool nicht herunterfahren. Für Mocha möchten Sie möglicherweise einen globalen Teardown-Hook untersuchen, siehe futurestud.io/tutorials/….

Aber um klar zu sein, dieser Benutzer hatte eine Arbeitsumgebung, und weil Mocha ihnen (im Wesentlichen) sagte, dass ihr perfekter Code falsch sei, verloren sie, wer weiß, wie viel Zeit es kostet, den Fehler zu lösen, den sie durch die Zerstörung ihrer Verbindungen verursacht haben. Und das ist nur diese eine unglückliche Person, die es zufällig in der Öffentlichkeit getan hat und die ich zufällig gesehen habe.

Also, ich denke , was ich versuche zu vermitteln, das nicht nur über das , was ist philosophisch richtig, noch ist es nur , dass einige Geräusche Nutzsignale verschleiern ... dieses Verhalten tatsächlich Schaden verursacht, und machen Programmierer Zeit Kippen Verschwenden bei Windmühlen.

Es tut mir leid, ich habe Ihren müden Punkt mit einer ehrlichen Frage verwechselt. Ich bedauere zu antworten. Vielleicht können die Entwickler diesen Thread sperren.

"mocha --reporter mocha-allure-reporter ./tests/controllers --exit" hat bei mir funktioniert. In der Tat ist das --exit eine sehr gute Problemumgehung. Ich verwende die Version 5.2.0 in meinem Projekt.

Gibt es eine Möglichkeit, den entsprechenden Effekt der Verwendung des Flags --exit erzielen, wenn Mokka " programmgesteuert " verwendet wird?

Ich sehe weder eine dokumentierte Option für exit / noexit noch eine allgemeine Möglichkeit, eine Flag-Zeichenfolge bei Verwendung der NodeJS-API zu übergeben.

Nach dem Muster anderer Optionen habe ich versucht:

const mocha = new Mocha({
    exit: true,
});

konnte aber nicht den gewünschten Effekt erzielen.

Eine flüchtige Überprüfung von https://github.com/mochajs/mocha/blob/master/lib/mocha.js scheint zu zeigen, dass diese Option nicht nur der Dokumentation, sondern auch der Quelle hinzugefügt werden muss.

Abgesehen von der Bereitstellung einer schnellen Lösung (verwenden Sie --exit ) stimme ich zu, dass sie das Kernproblem beim Auffinden der fehlerhaften Tests dem Benutzer überlassen haben. Ich habe jetzt selbst Probleme damit, aber wenn ich Hauptversionen aktualisiere, achte ich darauf, die Versionshinweise zu lesen und nicht blind zu aktualisieren

Wie genau bestehen Sie es? Dies ist mein package.json Skript

"scripts": { "test": "istanbul cover node_modules/mocha/bin/_mocha --exit test/Testcases/ " } und es funktioniert nicht

Abgesehen von der Bereitstellung einer schnellen Lösung (verwenden Sie --exit ) stimme ich zu, dass sie das Kernproblem beim Auffinden der fehlerhaften Tests dem Benutzer überlassen haben. Ich habe jetzt selbst Probleme damit, aber wenn ich Hauptversionen aktualisiere, achte ich darauf, die Versionshinweise zu lesen und nicht blind zu aktualisieren

Wie genau bestehen Sie es? Dies ist mein package.json Skript

"scripts": { "test": "istanbul cover node_modules/mocha/bin/_mocha --exit test/Testcases/ " } und es funktioniert nicht

Hatte das gleiche Problem und ich denke, ich bin nicht der einzige. Ich musste mich nur bewegen - am Ende beenden.
Das hat nicht funktioniert:
istanbul cover ./node_modules/mocha/bin/_mocha --exit - test / .test.jsDas hat mir geholfen:istanbul cover ./node_modules/mocha/bin/_mocha - test / .test.js --exit

exit macht nichts, wenn Mocha programmgesteuert ausgeführt wird, fwiw. Der Prozess wird vom CLI-Wrapper und nicht von Mocha-the-Library zwangsweise beendet.