Node.js, Mocha, machen globale Variablen in Closures verfügbar

8

Ich richte gerade einige Mokkatests mit Node ein und im Allgemeinen funktionieren sie. Ich bin jetzt auf ein Problem gestoßen, das ich nicht lösen kann.

Ich habe eine JS-Datei, die folgendes enthält: MyClass.js (Allgemeine CoffeeScript-Ausgabe für class MyClass + constructor: -> )

EDIT: Das ist Browser Code, ich möchte nur Node benutzen um es zu testen. (Ist das überhaupt wünschenswert?)

%Vor%

Ich benötige jetzt MyClass.js in meiner Testdatei. Sobald ich es ausführe, wirft es direkt einen Fehler

Testdatei:

%Vor%

Fehler:

%Vor%

Bisher verstehe ich, warum das passiert, Fenster existiert nicht in Node. Aber ich kann keine Lösung finden. Ich brauche das reale Objekt window eigentlich nicht, also dachte ich, es wäre genug, es zu verspotten. Aber es ist nicht ...

%Vor%

Dieser Befehl hilft auch nicht: $ mocha --globals window

Ich habe immer noch den gleichen Fehler. Jede Idee wird sehr geschätzt!

    
pabera 19.12.2013, 13:22
quelle

5 Antworten

3

Sie wollen eigentlich nicht das Fensterobjekt, was Sie wollen, ist das globale Objekt. Hier ist ein Code, der es im Browser bekommen kann (in diesem Fall ist es das gleiche wie 'Fenster') oder im Knoten (in diesem Fall ist es das gleiche wie 'global').

%Vor%

Dann setze Dinge auf das und nicht auf 'Fenster'.

Hinweis: Es gibt andere Möglichkeiten, das globale Objekt zu erhalten, aber das hat den Vorteil, dass es auch im strikten Moduscode funktioniert.

    
kybernetikos 16.01.2014 18:44
quelle
2

Mit folgendem Code können Sie Ihr klassenähnliches Objekt in der Web-Browser-Umgebung und Node.js ohne Modifikation verwenden. (Tut mir leid, ich weiß nicht, wie man das in CoffeeScript übersetzt) ​​

%Vor%

Da Sie bereits einen Bereich haben, der den globalen Namensraum nicht verschmutzt, können Sie ihn auf

reduzieren %Vor%

Ich bin kein Experte für AMD, require.js und andere Modullader, aber ich denke, es sollte einfach sein, dieses Muster zu erweitern, um auch andere Umgebungen zu unterstützen.

Bearbeiten

In einem Kommentar haben Sie gesagt, dass die obige Lösung nicht funktioniert, wenn sie zurück in CoffeeScript übersetzt wird. Daher schlage ich eine andere Lösung vor. Ich habe es nicht ausprobiert, aber vielleicht könnte dies ein Weg sein, um Ihr Problem zu lösen:

%Vor%

Es ist ein schreckliches Stück Code, aber wenn es funktioniert, ist es vielleicht zu Testzwecken ausreichend.

Aufgrund des Modulladeverhaltens von node.js funktioniert dies nur, wenn Ihre require('myclass.js') die erste Anforderung dieser Datei im Knotenprozess ist. Aber im Falle eines Tests mit Mocha sollte das stimmen.

    
hgoebl 10.01.2014 12:57
quelle
1

1) Was du suchst, ist module.exports , um Dinge in Node verfügbar zu machen:

Ссылка

2) Auch wenn Sie IIFE in Node nicht benötigen, können Sie die (function() {...

löschen

3) Sie können sich immer einige populäre Node-Repos auf Github ansehen, um Beispiele zu sehen, schauen Sie sich den Mocha-Code an, da Sie ihn benutzen, Sie werden ein oder zwei Dinge lernen.

    
plus- 19.12.2013 13:26
quelle
1

Etwas wie jsdom ist leichter als PhantomJS und bietet dennoch einige Dinge, die Sie zum Testen von Code benötigen, mit dem Sie rechnen müssen ein richtiger window . Ich habe es mit großem Erfolg verwendet, um den Code zu testen navigiert den DOM-Baum auf und ab.

Sie fragen:

  

Das ist Browsercode, ich möchte nur Node benutzen, um es zu testen. (Ist das überhaupt wünschenswert?)

Es ist sehr wünschenswert. Es gibt einen Punkt, an dem eine Lösung wie jsdom es nicht schneidet, aber solange Ihr Code innerhalb der Grenzen dessen ist, was jsdom behandelt, könnte es genauso gut nutzen und die Kosten für den Start einer Testumgebung auf ein Minimum reduzieren. p>     

Louis 19.12.2013 15:00
quelle
1

@hgoebl: Da ich nicht der OP bin, kann ich seinen originalen CoffeeScript-Code nicht hinzufügen, aber hier ist mein Beispiel:

pubsub.coffee:

%Vor%

jetzt der Test:

%Vor%

Was für mich bisher funktioniert ist:

%Vor%

und der Test:

%Vor%

Der Hauptnachteil der Lösung ist, dass ich das Fensterobjekt in der Implementierung und im Test explizit erwähnen muss. Benutzercode, der in einem Browser ausgeführt wird, sollte es weglassen können.

Ich habe jetzt eine andere Lösung gefunden:

%Vor%

und dann im Test, wobei einfach der PubSub-Namespace benötigt wird:

%Vor%

Und schließlich sieht die Lösung von kybernetikos wie folgt aus:

%Vor%

Wie jetzt befindet sich der PubSub-Namespace im globalen Namespace, nur eine einfache Anforderung wird in der Datei benötigt, die die Mocha-Tests enthält:

%Vor%     
Torsten Robitzki 10.01.2014 17:27
quelle

Tags und Links