Mocha: Opt-out von Globals

Selbst wenn es nur seinen Mist über den gesamten globalen Raum werfen würde, wenn Sie require('mocha') , wäre es besser als der aktuelle Stand der Dinge.

Ich finde es nicht albern, aber es gibt Kompromisse mit allem. Ich würde mich über so etwas freuen:

var Mocha = require('mocha');
var mocha = new Mocha(options);
mocha.describe('blah blah', function....

niemand würde es benutzen, aber zumindest wäre es eine sauberere Möglichkeit, das umzusetzen, was wir derzeit haben. Es würde eine Menge Boilerplate geben, die jeder jedes Mal einrichten müsste, aber wenn wir diese auf CLI-ish APIs eingrenzen könnten, wäre das in Ordnung. Selbst wenn es lib / cli.js gab, die gerade in der ARGV übergeben wurden, aber ich bezweifle immer noch, dass jemand sie verwenden würde, können Sie sie ohne die CLI einigermaßen einfach verwenden, aber das zeigt, dass niemand wirklich über einige Randfälle hinausgehen möchte.

@visionmedia das scheint ziemlich nett. Der Grund, warum ich require("mocha/bdd") oder ähnliches vorgeschlagen habe, ist, dass es ziemlich einfach wäre, es in Bezug auf vorhandenen Mokka zu implementieren, aber ja, deins ist wahrscheinlich besser. (Sie könnten sich vorstellen, es zu verwenden, um z. B. mehrere Testsuiten gleichzeitig auszuführen oder so. Nun, das würde wahrscheinlich aufgrund der Verwendung von process.on ('uncaughtException') kaputt gehen, aber Sie sehen, was ich meine.)

Ich kann eines Tages eine Pull-Anfrage für diesen versuchen.

Dies ist ein großartiges Beispiel, bei dem ein wenig zukünftiges JavaScript über die Destrukturierungszuweisung einen langen Weg zurücklegt.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/New_in_JavaScript/1.7#Destructuring_assignment_% 28Merge_into_own_page.2Fsection% 29

var [describe,it,beforeEach,afterEach] = new require("mocha")(options);

Ich wünschte nur, es gäbe Unterstützung für die Knotenharmonie.

Ist die Idee dazu in der Lage zu sein

node test/a-mocha-test.js

Und hat es diesen Test durchgeführt?

@glenjamin yup

Nachdem ich versucht hatte, dies selbst auf Nodespec zu tun, stellte das Problem nicht wirklich die verschiedenen Funktionen zur Verfügung, sondern stellte fest, wie / wann mit der Ausführung begonnen werden sollte - wir würden immer noch einen Zwei-Pass-Ansatz zum Definieren / Ausführen benötigen.

Die Optionen, die ich mir ausgedacht habe, waren:
1) Lassen Sie jeden Benutzer so etwas wie mocha.exec () am Ende jeder Datei hinzufügen, die er möglicherweise isoliert ausführen möchte
2) Warten Sie, bis der Core so etwas wie process.on ('exit') hinzugefügt hat, aber wenn die Ereignisschleife noch verfügbar ist
3) Nehmen Sie an, dass jede Datei nur einen Beschreibungsblock der obersten Ebene hat, und beginnen Sie mit der Ausführung, wenn dies abgeschlossen ist

(1) ist wahrscheinlich die schönste, die so aussehen könnte:

var run = require('mocha/required');

describe('blah blah' , function() {
// ..
});

run();

Dies scheint nicht viel dazu beizutragen, node ./node_modules/.bin/_mocha test/a-mocha-test.js tun, wenn Sie wirklich ohne den Wrapper mocha laufen müssen.

Ich denke, das passt nicht mehr dazu, wie Mokka derzeit verwendet wird. Da dieser Thread seit über einem Jahr inaktiv ist, schließe ich ihn vorerst.

Wenn jemand noch daran interessiert ist, kann er gerne einen Kommentar abgeben oder eine Pull-Anfrage vorschlagen, und wir werden darüber nachdenken :)

Könnte dies wieder geöffnet werden? Ich bin immer noch sehr daran interessiert. Nicht nur node test.js Mokka-Tests durchführen zu können, war einer der Hauptgründe, warum ich und meine Kollegen bei Mapbox von Mokka auf Kabelbäume wie Tape and Tap umgestiegen sind. Persönlich würde ich lieber bei Mokka bleiben, finde aber das Argument "Knotenfähigkeit" etwas überzeugend.

Bearbeiten: Das Argument "Knotenfähigkeit" wurde hier von @tmcw ausgearbeitet.

Aus Gründen der Klarheit ist das Fehlen einer require -fähigen Schnittstelle aus Anwendersicht hier nicht der primäre Blocker. Folgendes ist bereits dokumentiert, um zu funktionieren:

var describe = require('mocha').describe;
var before = require('mocha').before;
var it = require('mocha').it;

Und mit ES6 wird es noch schöner:

import { describe, before, it } from 'mocha';

Das Problem ist die Tatsache, dass dies nur funktioniert, wenn es über die Binärdatei mocha .

Oh, danke für die Klarstellung. :) Wenn wir diese Fähigkeit bereits anbieten, wenn wir sie mit der Mokka-Binärdatei ausführen, stimme ich zu, dass es schön wäre, dasselbe mit dem Knoten zu tun. Werde es untersuchen. Vielen Dank!

Jetzt, da der Knoten einen beforeExit-Hook hat, scheint dies ziemlich machbar zu sein.

Müsste so etwas sein

var { describe, it } = require('mocha/auto')

Ja. Wie TJ sagte, besteht das Problem darin, dass selbst wenn wir alles "knotenfähig" machen würden, möglicherweise zu viel Boilerplate erforderlich wäre, um nützlich zu sein.

Jedoch...

@glenjamin danke für das Heads-up zu beforeExit . Ich denke, wir könnten dies nutzen. Die Leute würden sich wahrscheinlich immer noch beschweren, dass es zu viel "Magie" ist ...

Ich habe 3cdd4a04c48193cceac6af7db72af06d380014a9 einen Proof-of-Concept hinzugefügt

Auf jeden Fall würde es ein bisschen Arbeit erfordern, aber ich denke, wir können es leicht für alle Schnittstellen verallgemeinern. Hier gibt es keine Unterstützung für Growl, mocha.opts oder verschiedene andere process -bezogene Dinge wie Exit-Codes. Wir sollten Code aus bin/_mocha extrahieren und hier wiederverwenden. Dann könnten wir auch Argumentationsunterstützung haben. Beispielsweise:

$ node test/my-test.js --reporter=dot

Wenn jemand irgendwelche Vorschläge hat, lass es mich wissen

Ich denke, einige der Dinge in bin/_mocha in eine Art CLI zu extrahieren, wäre trotzdem ziemlich sinnvoll.

Ich bin mir immer noch nicht sicher, ob dies wirklich eine nützliche Ergänzung ist.

Gibt es einen großen praktischen Unterschied zwischen den folgenden?

node test/test.js
./node_modules/.bin/mocha test/test.js
PATH=./node_modules/.bin:$PATH mocha test/test.js
npm test -- test/test.js

Ich habe das Gefühl, dass Leute, die keinen Mokka verwenden, weil sie keine Testdateien über node ausführen können, einfach Leute sind, die Mokka nicht mögen und nach einer Ausrede suchen! Mokka muss nicht jedermanns Sache sein: Lächeln:

Hier gilt das gleiche. Ich verwende jspm und SystemJS und kann in meinen Tests, die im Browser ausgeführt werden, nicht import Mocha verwenden.

import { describe, before, it } from 'mocha';

Kann nicht in Browsern verwendet werden.

@glenjamin es muss einfach passieren. Mokka sollte eine programmatische Kern-API haben. Ein netter Nebeneffekt davon sind knotenfähige Tests. Die Umgebung, in der es ausgeführt wird, verwendet die programmatische API, unabhängig davon, ob es sich um einen Browser, eine CLI oder etwas ganz anderes handelt. Mocha.app, jemand? :) :)

Interessiert an dieser Funktion!

+1 für:
import { describe, before, it } from 'mocha';

Wir haben derzeit const {describe, it} = require('mocha') , aber es ist nicht notwendig, da die Globals bereits existieren.

Wenn wir uns mit der Browserunterstützung befassen, können wir immer const {describe, it} = window.mocha tun. Wir müssen dies bereits für Chai tun.

Nun, const {describe, it} = window auch, nehme ich an.

Dies ist für die Architektur von Mokka so grundlegend, dass Mokka das globale Objekt im gebündelten Zustand

Ich denke nicht, dass Mokka einen anderen globalen als einen einzelnen Namespace definieren sollte, und vielleicht nur für Browser.

Die ausführbare Datei mocha weiterhin Globals. das wird sich wahrscheinlich nie ändern.

Was wir schießen können (und sollten), ist die Fähigkeit, Mokka-Tests einfach über node durchzuführen, ohne den globalen Namespace zu verschmutzen. Darum geht es in dieser Ausgabe.

Leider ist das ein texanischer Garnball, für den niemand die Zeit oder Energie hatte, sich zu entwirren, was sich im Alter dieser Ausgabe zeigen sollte ...

Die ausführbare Datei mocha weiterhin Globals. das wird sich wahrscheinlich nie ändern.

Obwohl ich nichts über die Struktur von Mokka weiß, kann ich behaupten, dass diese einzige Designauswahl die Ursache des Problems ist.

wahrscheinlich so!

Ich warf einen zweiten Blick auf den Code, fand (mehr oder weniger) heraus, was ich beim letzten Versuch, mich mit Globals herumzuschlagen, falsch gemacht hatte, und überlegte, was nötig wäre, um Testdateien mit node test/someFile.js ausführbar zu machen

• Globale vermeiden
  
  
  
  • Selbst in einem Semver Major können wir die überwiegende Mehrheit der Mokka-Nutzung, bei der die Globals verwendet werden, nicht brechen. Das Team konnte alle seine Tagesjobs kündigen, nie wieder schlafen, den Rest seiner Karriere damit verbringen und buchstäblich nicht genug Arbeitsstunden haben, um die unvorstellbare Flut von Supportanfragen zu bewältigen, die damit verbunden wären. Deshalb: Dies wird für immer hinter einer Flagge sein .
  
  
  • Derzeit sind die BDD- und TDD-Schnittstellen speziell gehüllt: Beide werden als require("mocha").it et al. Exportiert (und keine anderen Schnittstellen). (Hinweis: Der Grund, warum dies bei Auswahl anderer Schnittstellen nicht funktioniert, kann sein, dass Mocha einen Fehler hat, bei dem unter den meisten Umständen die BDD-Schnittstelle eingerichtet wird, auch wenn eine andere ausgewählt ist. # 2207) Ich möchte davon abweichen.
  
  
  • Benutzerdefinierte Schnittstellen (von Drittanbietern) sollten mit dem Exportschema arbeiten können (sofern sie das ausgegebene Kontextobjekt anstelle der Hardcodierung von global ).
  
  
  • Wir können nicht jede mögliche Schnittstelle haben, die ihre Funktionen zu Mocha hinzufügt (was require("mocha") exportiert).
  
  
  • Wenn wir jemals den Fehler beheben, bei dem die BDD-Schnittstelle immer eingerichtet ist, wird es schwierig sein, die BDD- und TDD-Schnittstellen auch weiterhin auf Mocha exportieren. Eine andere Schnittstelle wird ausgewählt.
  
  
  • Sie sollten Mochas Benutzeroberfläche sowieso nicht auf TDD einstellen und die BDD-Schnittstelle verwenden oder umgekehrt, es sei denn, Sie tun require("mocha/tddInterface").test oder require("mocha/interface/bdd").it (nicht zu verwechseln mit "mocha/lib/interfaces/<interface name>" wo die Implementierungen leben).
  
  
  • Wir könnten vielleicht das Export-BDD-und-TDD-auf-Mokka-wenn-möglich-Verhalten für Abwärtskompatibilität bis zu einem Semver-Major beibehalten. Ich gehe nicht davon aus, dass sich viele Leute beschweren werden, wenn wir es fallen lassen, da die Leute, die es angefordert haben und es verwenden, mehr über das, was sie tun, wissen als die meisten und sowieso nicht ganz zufrieden sind (seit dem Globale sind immer noch da).
  
  
• Knotenfähigkeit, dh in der Lage zu sein, node test/someFile.js anstelle von mocha test/someFile.js auszuführen
  
  
  
  • Es ist zwar weniger allgegenwärtig als die globalen, aber ich glaube nicht, dass wir es uns leisten können, Leute zu brechen, die var Mocha = require("mocha"); var mocha = new Mocha() usw. verwenden (dh die "programmatische Schnittstelle"). Wir müssten dies entweder erkennen und vermeiden, Mocha "auf knotenfähige Weise" auszuführen, oder (für uns einfacher, erfordert jedoch die Anmeldung von Benutzern) den Zugriff auf die Knotenfähigkeit über einen anderen Import erfordern, z. B. require("mocha/nodeable").it ( .describe usw.). Ein spezieller Import anstelle von Huckepack auf require("mocha") wäre einfacher sicher zu implementieren und würde meinem Wunsch (beschrieben und begründet im Abschnitt Vermeiden von Globals) entsprechen, nicht mehr Schnittstellen für das Mocha -Objekt zu exportieren exportiert von require("mocha") .
  
  
  • Um node test/someFile.js , reicht es nicht aus, dass someFile.js Mochas Schnittstelle importieren kann: Mocha muss instanziiert werden, und nachdem alle Tests eingerichtet sind, muss Mocha ausgeführt werden. Mit anderen Worten, require("mocha/nodeable") muss Mocha instanziieren sowie die Schnittstelle exportieren und dann ... nachdem die Testdatei ausgeführt wurde, muss Mocha ausgeführt werden.
  
  
  • Eine Möglichkeit, dies zu tun, besteht darin, Mocha in process.on("beforeExit" auszuführen, vorausgesetzt, die Testdatei startet keine asynchronen Aktionen.
  
  
  • Eine andere Möglichkeit, dies zu tun, wäre, Mocha in process.nextTick oder setImmediate oder setTimeout(..., 0 /* or some small number */) auszuführen.
  
  
  • Tests, die ihre Daten mit --delay einrichten und asynchron mit run() wären ein Problem. Nicht um zu wissen, wann es laufen soll - das ist einfacher, es gibt run() - und nicht einmal um zu wissen, ob --delay (siehe unten oder require("mocha/nodeable/delayed") ), sondern weil run() soll nur in einer Testdatei aufgerufen werden, wie sie derzeit entworfen wurde. Wahrscheinlich ist es bereits schwierig, mit diesem Design zu arbeiten, und wir müssten es korrigieren, damit run() sowieso in jeder Testdatei aufgerufen werden sollte. In diesem Fall wäre es einfach, es mit "knotenfähigen" Tests zu verwenden es reparieren. Ansonsten ... bin ich mir nicht sicher, was ich tun soll.
  
  
  • Wenn wir in der Lage sein möchten, das Aufrufen dieser Testdateien über mocha anstelle von node zuzulassen (dh wenn dies nicht die Verwendung von node erzwingt), dann ist was auch immer require d muss erkennen, wann die CLI verwendet wird, und dann Mocha nicht instanziieren. Dies ist einfacher als zu erkennen, wann die programmatische API verwendet wird. Die CLI kann einen globalen Status festlegen, den diese Module prüfen würden, oder diese Module können prüfen, ob die CLI die von Node ausgeführte Datei ist.
  
  
  • Wir müssten die CLI-Teile modularer gestalten, wenn wir das Übergeben von Mocha-Flags beim Durchlaufen von Node oder bei der Verwendung von mocha.opts unterstützen möchten oder alles, was es knotenfähigen Testdateien ermöglichen würde, ein anderes Verhalten als Mochas Standard zu verwenden Verhalten.
  
  
• Ich kombiniere die Einschränkungen dieser beiden Ideen und
  
  
  
  • Globale vermeiden
  
  
  • Anstatt Schnittstellen an das global -Objekt zu übergeben, auf das ihre Funktionen gestellt werden sollen, wird ihnen ein "ausgewähltes Schnittstellenobjekt" übergeben. (BEARBEITET ZUM HINZUFÜGEN: Dies muss sowohl in lib/mocha.js als auch in browser-entry.js . Soweit mir bekannt ist, sind alle global relevanten Teile des Vorschlags sowohl in Node als auch im Browser möglich. )
  
  
  • Anschließend wird der gesamte Inhalt des ausgewählten Schnittstellenobjekts in global kopiert.
  
  
  • Eine localInterface -Option ( --local-interface in der CLI) verhindert, dass Mocha vom ausgewählten Schnittstellenobjekt nach global kopiert.
  
  
  • DEBATIERBAR: Aus Gründen der Abwärtskompatibilität mit require("mocha").it kopiert Mocha zunächst auch TDD / BDD-Funktionen vom ausgewählten Schnittstellenobjekt auf Mocha , dies wird jedoch später veraltet / entfernt.
    
    
    
    
    
    • (HINWEIS: Wenn wir verhindern, dass BDD eingerichtet wird, wenn es nicht ausgewählt ist, müssen wir hier möglicherweise noch speziellere Maßnahmen ergreifen, um das BDD auf einem Dummy-ausgewählten Schnittstellenobjekt einzurichten, von dem diese kopiert werden können - ein guter Fall zum Löschen Das Verhalten insgesamt wird immer komplexer, je mehr andere Dinge wir reparieren / verbessern, während wir immer noch versuchen, dies zu unterstützen.)
    
    
    
  
  
  • require("mocha/interface") exportiert das ausgewählte Schnittstellenobjekt.
  
  
  • require("mocha/interface/<specific interface>") ruft die angegebene Schnittstelle mit einem neuen ausgewählten Schnittstellenobjekt auf, das anschließend exportiert wird.
  
  
  • BEARBEITET ZUM HINZUFÜGEN: require("mocha/interface") ist auch eine Eigenschaft des mocha -Objekts im Browser, mocha.interface , um die Browsernutzung ohne Modulsystem zu unterstützen.
  
  
  • Knotenfähigkeit
  
  
  • require("mocha/nodeable/<specific interface>") instanziiert Mocha, richtet Mocha so ein, dass es nach der Testdatei ausgeführt wird (vermutlich unter Verwendung von setTimeout sofern nicht delay verwendet wird, siehe oben zu delay ) und Exportieren Sie ein ausgewähltes Schnittstellenobjekt für diese Schnittstelle ähnlich wie require("mocha/interface/<specific interface>")
  
  
  • Wenn CLI-Optionen oder mocha.opts unterstützt werden, würde require("mocha/nodeable") Mocha instanziieren, Mocha so einrichten, dass es nach der Testdatei ausgeführt wird (siehe oben), und dieselben Schritte zur Einrichtung der Schnittstelle wie die CLI ausführen und die exportieren ausgewähltes Schnittstellenobjekt genau wie require("mocha/interface") .
  
  
  • Wenn knotenfähige Testdateien auch mocha -fähig sein sollen, dann ist mocha/nodeable & mocha/nodeable/<specific interface> nicht erforderlich, wir können die Knotenfähigkeit auf mocha/interface zurücksetzen. mocha/interface/<specific interface> .
  
  

Gedanken?

Nach weiteren Überlegungen beantrage ich, dieses Ticket aus folgenden Gründen gegen die Verwendung von node <test file> anstelle von mocha <test file> :

• Mir sind keine Vorteile bekannt.
  
  
  
  • Eine mögliche Idee ist, dass nur eine einzige Testdatei ausgeführt wird, unabhängig davon, welche Globs in mocha.opts . Einfache Lösung: Fügen Sie stattdessen Globs in das Skript test in package.json ein: npm test führen alle aus und mocha ( node_modules/.bin/mocha , npx mocha ) führt nur die angegebenen Testdateien aus. (Dateien oder Globs, die für jeden Testlauf ausgeführt werden sollen, unabhängig davon, wie viele Testdateien ausgeführt werden, sollten weiterhin in mocha.opts .)
  
  
  • Eine andere mögliche Idee ist, dass es erlaubt, mocha.opts insgesamt zu umgehen. Dies sollte jetzt mit mocha --opts /dev/null (oder unter Windows mocha --opts nul ) möglich sein. Wenn dies aus irgendeinem Grund nicht der Fall ist, ist es einfacher, ein CLI-Flag zu implementieren, um die Verarbeitung von mocha.opts zu überspringen.
  
  
• Es kann außerhalb von Mokka implementiert werden; Anstelle von "mocha/nodeable" fügen Sie einfach denselben Code mithilfe der programmgesteuerten API von Mocha in ein hypothetisches Paket "nodeable-mocha" .
  
  
  
  • Ich sage nicht, dass es an erster Stelle einfach zu implementieren wäre. Ich sage, dass mir nicht bewusst ist, wie es schwieriger sein könnte, es zu implementieren, weil ich mich außerhalb von Mocha befinde.
  
  

Sollten wir einen signifikanten Vorteil entdecken, der im Kern leichter zu erreichen ist als außerhalb, können wir jederzeit wieder öffnen.

Ich beantrage jedoch auch die Wiedereröffnung des Vermeidungs-Globals-Tickets, weil:

• Obwohl es unwahrscheinlich ist, dass die Vorteile relevant sind (wie viele andere Bibliotheken verwenden Globals mit den Namen describe , it usw.?), Sind sie im Prinzip möglich (die Antwort auf diese Frage könnte größer sein als 0, jedoch nur wenige) - es ist theoretisch das Richtige, Dinge nicht in den globalen Namespace zu werfen.
  
  
  
  • Darüber hinaus würde mein Plan dasselbe Verhalten auf Schnittstellen von Drittanbietern ausweiten, die korrekt geschrieben sind, um das ausgegebene "Kontext" -Objekt (für das Mocha derzeit immer das globale Objekt verwendet) zu verwenden, anstatt das globale Objekt fest zu codieren. Während es unwahrscheinlich ist , dass unsere eigenen Schnittstellen andere Bibliotheken stören, können wir keine Garantie für andere Schnittstellen übernehmen, sodass wir es ihnen leichter machen würden, auch das Richtige zu tun.
  
  
• Mein Plan würde viele verwandte Randfälle im aktuellen Verhalten bereinigen (z. B. Erweiterung auf Schnittstellen von Drittanbietern, aber auch Konsistenz in Mocha, anstatt die BDD- und TDD-Schnittstellen speziell zu behandeln).
• Die einzige einfache Möglichkeit, es außerhalb von Mocha zu implementieren, besteht darin, die programmatische API von Mocha zu verwenden und es mit Affen zu patchen. Dies würde auch einige der oben genannten Inkonsistenzen und Randfälle hinterlassen.

Sie schlagen also eher vor, dass Mocha eine Möglichkeit bietet, Tests mit mocha durchzuführen, aber hinter einer Flagge, die global nicht verschmutzt?

Ein Teil dessen, was Mokka zu Mokka macht, und ein Teil seines Erfolgs ist, dass es keine Boilerplate benötigt, um Sachen zu importieren. Trotz des Dogmas, den globalen Namespace zu verschmutzen, gibt es völlig gültige Gründe für die Ergonomie der Entwickler.

Sie schlagen also eher vor, dass Mokka eine Möglichkeit bietet, Tests mit Mokka durchzuführen, aber hinter einer Flagge, die die Welt nicht verschmutzt?

Jawohl.

Ein Teil dessen, was Mokka zu Mokka macht, und ein Teil seines Erfolgs ist, dass es keine Boilerplate benötigt, um Sachen zu importieren. Trotz des Dogmas, den globalen Namespace zu verschmutzen, gibt es völlig gültige Gründe für die Ergonomie der Entwickler.

Ich sage nicht, dass ich im Allgemeinen nicht einverstanden bin, aber als Opt-In-Funktion kann ich sehen, wo einige Entwickler Importe anstelle von Globals wünschen (möglicherweise möchten sie, dass ihr Modul eine lokale Variable context benennt, ohne versehentlich darauf zu verweisen Wenn sie var vergessen, möchten sie vielleicht eine Schnittstelle eines Drittanbieters verwenden, bei der diese Art von Kollision noch wahrscheinlicher ist. Und jetzt, wo ich herausgefunden habe, wie man es richtig macht, ist es Auch in Mokka einfacher zu machen als als eine Art Add-On (wenn ich nicht in etwas anderes hineingezogen werde, werde ich diese Woche wahrscheinlich einen groben Entwurf in einem Zweig zusammenwerfen, um dies zu demonstrieren).

(Außerdem führen wir bereits einen Sortierversuch durch, bei dem die Schnittstelle, nachdem sie global eingerichtet wurde, auf das Objekt Mocha kopiert wird, sodass Sie require("mocha").it , aber die Version, die wir bereits haben Offen gesagt zu warten ist seltsam, inkonsistent , fehleranfällig und vermeidet nicht einmal, den globalen Namespace zu verschmutzen. Wenn wir diese Art von Funktion überhaupt beibehalten, können wir sie genauso gut korrigieren , anstatt eine zweifelhafte Version beizubehalten.)

Dies ist IMO im Gegensatz zu node <test file> für Mokka-Tests, was meines Wissens keinen Vorteil hat und innerhalb oder außerhalb von Mokka gleichermaßen schwer zu implementieren wäre.

@ Stevenvachon
Wie kommt es, dass const {describe, it} = require('mocha') bei mir nicht funktioniert? Ich habe gerade undefinierte ...

$ node -v
v8.4.0

@zapphyre Sie müssen die Testsuite weiterhin über das Programm mocha ausführen, nicht über node .

Sie können nicht mehrere Quelldateien mit node ausführen, daher bleiben Sie bei mocha . Ich kenne keinen Test Runner / Framework, der keine eigene ausführbare Datei hat.

Der Titel der Ausgabe wurde aktualisiert, um genauer zu sein

Ein weiterer Grund dafür: Ich möchte Tests mit einer anderen JS-Laufzeit ausführen , z. B. mocha aufrufen muss, um Tests auszuführen.

Ich meine, du machst es schon für den Browser. Auf dieser Plattform habe ich JS-Code, der "Mokka" importiert und dann die Tests von einem globalen mocha -Objekt mit mocha.run() .

Im Browser I.

• Laden Sie Mokka und erhalten Sie ein globales mocha Objekt
• Führen Sie mocha.setup({ui: 'bdd'});
• Laden Sie alle Testdateien mit SystemJS
• Dann renne ich

      mocha.checkLeaks();
      mocha.globals([]);
      mocha.run();

Und das ist es. Wenn ich dasselbe in node.js versuche und anstelle von SystemJS eine require-Anweisung zum Laden einer Testdatei verwende, erhalte ich (mit mocha 5.2.0)

> mocha.run();
TypeError: Cannot read property 'search' of undefined
    at Mocha.mocha.run (/home/mha/one/node_modules/mocha/mocha.js:149:54)

BEARBEITEN: Ich habe versucht, https://github.com/mochajs/mocha/wiki/Using-Mocha-programmatisch und mocha.addFile anstatt es nur zu laden, das gleiche Ergebnis.

Gibt es derzeit eine Möglichkeit zum Importieren / Beschreiben?

Es gibt eine neue (ab sofort 20 Stunden alte) Wiki-Seite https://github.com/mochajs/mocha/wiki/Using-mocha-programmatisch , die jedoch zum Ausführen der Tests dient.

Ein weiterer Grund dafür: Ich möchte Tests mit einer anderen JS-Laufzeit ausführen , z. B. mocha aufrufen muss, um Tests auszuführen.

Wenn die alternative Laufzeit eine knotenähnliche ausführbare Datei hat (was meiner Meinung nach low.js tut?), Können Sie alternative-executable ./node_modules/.bin/_mocha ausführen, und das sollte funktionieren

Ich kenne keinen Test Runner / Framework, der keine eigene ausführbare Datei hat.

https://github.com/tapjs/node-tap/#tutti -i-gusti-sono-gusti

Nachdem https://github.com/mochajs/mocha/issues/3006 behoben wurde, wäre es schön, gleichnamige Exporte im Browser zu haben.

Derzeit funktioniert Folgendes:

<script type="module">
  import './node_modules/mocha/mocha.js'
  console.log(mocha)
</script>

Aber das ist nicht:

<script type="module">
  import { mocha } from './node_modules/mocha/mocha.js'
  console.log(mocha)
</script>

(wie von https://github.com/mochajs/mocha/issues/956#issuecomment-167453800 angefordert)

Dies könnte einfacher werden, wenn wir unseren Zweig mit Roll-up zusammenführen und Transpiler einrichten. Es scheint machbar, ein ESM-Bundle und ein Legacy-Bundle zu haben, die die ESM-Codepfade verbrauchen und die globalen Lecks hinzufügen. Wir müssten sehr vorsichtig sein, um nur Änderungen an neu hinzugefügten Codepfaden und -paketen vorzunehmen, damit wir nicht sowohl in Browsern als auch in Knoten brechen oder codieren

Mit globalen Vars und Typisierungen macht dies nur Mokka-Legacy-Sache.

Übrigens hat gerade @types/mocha ohne Globals erstellt: https://github.com/whitecolor/mocha-types

Hoffe, dass sie (Globals) bald offiziell entfernt werden.