Stub save Instanz Methode des Mongoose-Modells mit Sinon

8

Ich versuche eine Dienstfunktion zu testen, die ich verwende, um ein Widget mit einem Mongoose-Modell zu speichern. Ich möchte die Methode zum Speichern von Instanzen in meinem Modell ausschließen, aber ich kann keine gute Lösung finden. Ich habe andere Vorschläge gesehen, aber keine scheint vollständig zu sein.

Siehe ... dies und dies .

Hier ist mein Modell ...

%Vor%

Hier ist mein Service ...

%Vor%

Mein Service ist sehr einfach. Es akzeptiert einige JSON-Daten, erstellt ein neues Widget und speichert das Widget dann mit der Instanzmethode "save". Es ruft dann zurück und übergibt einen Fehler und ein Dokument basierend auf dem Ergebnis des Speicheraufrufs.

Ich möchte das nur testen, wenn ich createWidget ({title: 'Widget A'}) ...

anrufe
  • Der Widget-Konstruktor wird einmal mit den Daten aufgerufen, die ich an die Service-Funktion
    • übergeben habe
  • Die Methode save instance für das neu erstellte Widget-Objekt wird einmal
    • aufgerufen
  • EXTRA CREDIT: Die Methode der gespeicherten Instanz ruft null für den Fehler und {title: 'Widget A'} für das Dokument zurück.

Um das isoliert zu testen, müsste ich wahrscheinlich ...

  • Mock oder stub den Widget-Konstruktor, damit er ein Mock-Widget-Objekt zurückgibt, das ich als Teil meines Tests erstellt habe.
  • Stot die Speicherfunktion des Mock-Widget-Objekts, damit ich kontrollieren kann, was passiert.

Ich habe Probleme herauszufinden, wie ich das mit Sinon machen kann. Ich habe mehrere Varianten auf den Seiten von SO ohne Glück versucht.

HINWEISE:

  • Ich möchte ein bereits erstelltes Modellobjekt nicht an den Dienst übergeben, weil ich möchte, dass der Dienst das Einzige ist, das über Mungo "weiß".
  • Ich weiß, dass dies nicht der größte Deal ist (um das nur mit einem Integrations- oder End-to-End-Test zu testen, aber es wäre schön, eine Lösung zu finden.

Vielen Dank für Ihre Hilfe.

    
Kevin 12.03.2014, 01:51
quelle

3 Antworten

5

Wenn ich das testen würde, würde ich so vorgehen, zuerst eine Möglichkeit, mein verspottetes Widget in den Widget-Dienst zu injizieren. Ich weiß, dass es einen -Hijack Node-Hijack , Spott gibt oder so ähnlich wie node-di , sie haben alle unterschiedliche Stile, ich bin mir sicher, dass da mehr ist. Wähle einen aus und benutze ihn.

Sobald ich das richtig verstanden habe, erstelle ich meinen Widget-Service mit meinem Mock-Widget-Modul. Dann mache ich so etwas (das verwendet mocha übrigens):

%Vor%

Dies ist nur ein Beispiel, meine Tests werden manchmal komplizierter. Es kommt vor, dass die Backend-Aufruf-Funktion (hier ist es, widget.save), die ich spotten möchte, diejenige ist, die ich möchte, dass sich ihr Verhalten mit jedem anderen Test ändert, deshalb lege ich den Stub jedes Mal zurück .

Hier ist auch ein anderes Beispiel für ähnliche Dinge: Ссылка

    
Farid Nouri Neshat 19.03.2014, 14:15
quelle
3

So würde ich es machen. Ich benutze Mocker , um das Laden des Moduls zu manipulieren. Der Code von widgetservice.js muss geändert werden, damit require('./widget'); ohne die Erweiterung .js aufgerufen wird. Ohne die Änderung funktioniert der folgende Code nicht, da ich die allgemeine empfohlene Vorgehensweise zur Vermeidung von Erweiterungen in require -Aufrufen verwende. Spott ist klar, dass die Namen, die an den Aufruf require übergeben werden, genau übereinstimmen müssen.

Der Testläufer ist Mocha .

Der Code folgt. Ich habe umfangreiche Kommentare in den Code selbst geschrieben.

%Vor%

Sofern ich etwas nicht verpasst habe, deckt dies alle Tests ab, die in der Frage erwähnt wurden.

    
Louis 21.03.2014 12:39
quelle
3

Mit der aktuellen Version von Mongoose können Sie create method

verwenden %Vor%

Dann, um die Methode zu testen (mit Mocha)

%Vor%

Auch, wenn Sie verkettete Methoden verspotten möchten, verwenden Sie sinon-mongoose .

    
Gon 13.11.2015 18:37
quelle

Tags und Links

Django: Verwenden von Annotate, Count und Distinct in einem Queryset Flask 404 bei Verwendung von SERVER_NAME