Node.js-Komponententests [closed]

Lesezeit: 5 Minuten

Markieren

Gibt es derzeit gute Unit-Testing-Frameworks für Node.js (serverseitiges JavaScript)?

Ich suche nach etwas etwas Tieferem als dem bereitgestellten Assert-Modul.

böse Sellerie

Am Ende habe ich verwendet Knoteneinheit und bin echt happy damit.

Ich benutzte Expresso ursprünglich, aber die Tatsache, dass Tests parallel ausgeführt werden, verursachte einige Probleme. (Zum Beispiel funktioniert die Verwendung von Datenbank-Fixtures in dieser Situation nicht gut.)

Expresso zwingt Sie nicht, Tests parallel auszuführen. Füttere es mit dem Argument –serial und es führt sie alle in fröhlicher Reihenfolge aus.

– Einaros

31. August 2011 um 10:27 Uhr
Gerade heruntergeladen und benutzt nodeunit … macht genau das, was es sagt, funktionierte beim ersten Mal ftw!

– Michael Dausmann

25. Februar 2012 um 6:21 Uhr
Nodeunit ist etwas seltsam, da jeder Test aufgerufen werden muss .done() meiner bescheidenen Meinung nach.

– Kos

6. November 2012 um 12:53 Uhr
Wenn ich jetzt ein neues Projekt starten würde, würde ich wahrscheinlich Mocha als Testframework verwenden

– böse Sellerie

6. November 2012 um 16:30 Uhr
Nodeunit erfordert .done() um asynchrone Tests zu ermöglichen. Ich stimme zu, dass es manchmal etwas unhandlich sein kann, aber es hat einen mächtigen guten Grund, es so zu machen.

– L0j1k

28. Mai 2014 um 6:42 Uhr

bennidi

Ich habe auch nach einem anständigen Testframework für node gesucht und bin fündig geworden Mokka. Es ist der offizielle Nachfolger von Expresso und wirkt sehr erwachsen.

Es ermöglicht das Plug-in verschiedener Assertion-Bibliotheken, es bietet Reporter für die Codeabdeckung und andere Dinge (Sie können Ihre eigenen Plug-ins hinzufügen). Es kann synchron oder asynchron laufen und verfügt über eine übersichtliche API.

Ich werde es ausprobieren und berichten…

BEARBEITEN:

Nachdem ich unglaublich viel Zeit für andere Projekte aufgewendet hatte, kam ich endlich zu einem JavaScript-Projekt zurück und hatte Zeit, mit Mocha herumzuspielen. Ich kann die Verwendung ernsthaft empfehlen. Die Tests lesen sich sehr schön, Integration mit Gulp.js ist großartig und Tests laufen sehr schnell. Ich konnte sowohl automatische Standalone- als auch In-Browser-Einrichtungen (Browserify) Testläufe und entsprechende Codeabdeckungsberichte in etwa einem halben Tag (die meiste Zeit wird damit verbracht, zu verstehen, wie Browserify von Gulp.js verwendet wird). Für mich scheint Mocha eine sehr gute Wahl für ein Testframework zu sein.

AKTUALISIEREN:

Ich bin nach wie vor sehr überzeugt von Mocha. Integration mit Tschai ermöglicht es, verschiedene Behauptungsstile einzufügen. Sie können ein funktionierendes Setup in auschecken dieses GitHub-Projekt. Ich verwende es jetzt mit Karma, integriere Codeabdeckungsbericht, automatische Beobachter und gute Integration mit IntelliJ-IDEE.

Erste Schritte mit Mokka – brianstoner.com/blog/testing-in-nodejs-with-mocha

– Nikolaus Blasgen

25. Oktober 2016 um 2:19 Uhr

Einaros

Ich persönlich bin dabei geblieben Expressoaber es gibt eine Reihe verschiedener Frameworks, die die meisten Teststile unterstützen.

Joyent hat eine umfangreiche Liste; Probieren Sie es aus.

Expresso ist das einzige, das für mich sinnvoll ist und mit asynchronem Code richtig funktioniert. Versuchte auch Gelübde und Qunit.

– balupton

20. September 2011 um 10:53 Uhr

jtsao22

Ich persönlich habe nur das Assert-Modul verwendet, aber ich möchte auch mehr. Ich habe viele Node.js-Module und beliebte Unit-Testing-Frameworks durchgesehen Knoteneinheit und sollte (das vom selben Typen wie Espresso hergestellt wird (vielleicht ein aktualisierter Name?)

Gelübde sieht auch vielversprechend aus.

Raynos

Gelübde ist eine solide Unit-Testing-Bibliothek für Node.js, aber die Syntax ist langwierig.

Ich habe eine dünne Abstraktion namens geschrieben Gelübde fließend wodurch die API verkettbar wird.

Und ich habe eine weitere Abstraktion geschrieben, [vows-is] die auf Gelübde fließend aufbaut und eine aussetzt BDD Stil-Syntax.

Ein Beispiel wäre

var is = require("vows-is");

is.suite("testing is fun").batch()

    .context("is testing fun?")
        .topic.is("yes")
        .vow.it.should.equal("yes")

.suite().run({
    reporter: is.reporter
});

Mehr Beispiele.

Amen dazu, die Syntax der Gelübde ist meiner Meinung nach schrecklich

– Don Felker

10. Februar 2012 um 3:18 Uhr
Hatte ein Spiel mit Gelübden mit dem Appeasy-Wrapper. Sah nach einer guten Idee zum Testen einer JSON-API aus, kam aber schnell zu kurz. Ich neige auch dazu, festzustellen, dass APIs, die stark auf solche Verkettungsaufrufe ausgerichtet sind, schwierig zu verwenden und schwer zu debuggen sind. Sie sehen in Beispielen gut aus, funktionieren aber in der Praxis nicht gut.

– Drekka

12. Juni 2012 um 3:34 Uhr
@drekka Gelübde und Gelübde sind schrecklich. Mokka verwenden

– Raynos

12. Juni 2012 um 5:41 Uhr
Versuchen Sie es jetzt, scheinen aber auf ähnliche Probleme zu stoßen.

– Drekka

12. Juni 2012 um 6:01 Uhr
dann musst du es falsch verwenden. versuche zu lesen gist.github.com/2896455. @Drekka

– Raynos

12. Juni 2012 um 15:28 Uhr

Peter Mortensen

Ich denke, unter den verschiedenen verfügbaren Test-Frameworks, Mokka ist die neueste und sehr einfach zu implementieren. Hier ist ein wunderbares Tutorial zur Verwendung:

Wie Sie Ihre Rest-API mit Node.js, Express und Mocha erstellen und testen

Amen dazu, die Syntax der Gelübde ist meiner Meinung nach schrecklich

– Don Felker

10. Februar 2012 um 3:18 Uhr
Hatte ein Spiel mit Gelübden mit dem Appeasy-Wrapper. Sah nach einer guten Idee zum Testen einer JSON-API aus, kam aber schnell zu kurz. Ich neige auch dazu, festzustellen, dass APIs, die stark auf solche Verkettungsaufrufe ausgerichtet sind, schwierig zu verwenden und schwer zu debuggen sind. Sie sehen in Beispielen gut aus, funktionieren aber in der Praxis nicht gut.

– Drekka

12. Juni 2012 um 3:34 Uhr
@drekka Gelübde und Gelübde sind schrecklich. Mokka verwenden

– Raynos

12. Juni 2012 um 5:41 Uhr
Versuchen Sie es jetzt, scheinen aber auf ähnliche Probleme zu stoßen.

– Drekka

12. Juni 2012 um 6:01 Uhr
dann musst du es falsch verwenden. versuche zu lesen gist.github.com/2896455. @Drekka

– Raynos

12. Juni 2012 um 15:28 Uhr

Zorayr

Wenn Sie sich auskennen QUnitDu könntest benutzen Knoten-Quint Dies ist eine Art Node-Wrapper um das vorhandene Framework von QUnit.

12834400cookie-checkNode.js-Komponententests [closed]

#Javascript #node.js #Unit-Tests