Node.js behaupten Bibliothek im Vergleich zu anderen assert Bibliotheken

Question

Nach node.js Bibliothek behaupten documentation:

Das Modul für den internen Gebrauch von Node.js gedacht, kann aber über erfordern in Anwendungscode verwendet werden ('behaupten'). Assert ist jedoch kein Test-Framework und soll nicht als universelle Assertion-Bibliothek verwendet werden.

Ich war bei Chai als Alternative Assertion-Bibliothek (kein BDD API, nur die assert API) und am Ende der Suche ich sehe, dass die Assertion Funktionalität sehr ähnlich ist.

Warum Chais Assert-Bibliothek ist eine bessere Assert-Bibliothek? Es macht alles, was node.js (abgesehen davon, dass es nur in Bezug auf die Behauptung verfügbar ist, aber das ist nur syntaktische Zuckerbeschichtung). Selbst einfache Dinge wie die Gesamtanzahl der ausgeführten Assert sind bei beiden nicht verfügbar.

Fehle ich etwas?

Answer 1

UPDATE (April 2017): Node.js warnt Benutzer nicht mehr davor, assert zu verwenden, daher ist die Antwort unten veraltet. Ich verlasse es jedoch auf historisches Interesse.

Hier ist the answer I posted to a very similar question on the Node.js issue tracker.

https://github.com/nodejs/node/issues/4532 und andere Fragen verweisen auf den Grund der Dokumentation gegen Tests mit assert für Einheit empfiehlt: Es gibt Rand Fall Bugs (oder zumindest sicher überrascht) und fehlende Funktionen. Ein wenig mehr Kontext: Wissend, was wir jetzt wissen, wenn wir Node.js Kern wieder vollständig entwarfen/bauten, würde das assert Modul entweder nicht in Node.js existieren oder aber aus weitaus weniger Funktionen bestehen - durchaus möglicherweise nur assert() (das ist derzeit ein Alias ​​für assert.ok()).

Die Gründe dafür, zumindest aus meiner Sicht sind:

• die ganze Zeug in assert getan leicht in Userland
• Kern Anstrengungen besser an anderer Stelle ausgegeben werden, durchgeführt werden, um einen Unit-Tests als Perfektionierung Modul, das in Userland getan werden kann

Es gibt zusätzlichen Kontext, andere können hier oder nicht hinzuzufügen (wie, warum, alle Dinge gleich ist, würden wir bevorzugen Kern klein zu halten und die Dinge in Userland tun). Aber das ist die sogenannte 30.000-Fuß-Ansicht.

Seit assert in Node.js für eine lange Zeit gewesen ist und eine Menge des Ökosystems davon abhängt, sind wir unwahrscheinlich (mindestens so gut, wie ich zur gegenwärtigen Zeit sagen kann), assert.throws() und Freunde jemals zu entfernen. Es würde zu viel Zeug zerbrechen. Aber wir können Menschen davon abhalten, assert zu verwenden, und sie dazu ermutigen, Userland-Module zu verwenden, die von Leuten gepflegt werden, die sich sehr um sie kümmern und die Edge-Case-Bugs aggressiv beheben und neue nützliche Funktionen hinzufügen. Darum geht es also.

Richtig, wenn Sie einfache Behauptungen mit einfachen Fällen tun, wird assert wahrscheinlich Ihre Bedürfnisse erfüllen. Aber wenn Sie jemals assert herauswachsen, werden Sie besser mit chai oder was auch immer sein. Deshalb ermutigen wir Menschen, dort zu beginnen. Es ist besser für sie (normalerweise) und besser für uns (normalerweise).

Ich hoffe, das ist hilfreich und beantwortet Ihre Frage.

Answer 2

Ich nehme an, da mir niemand gutes Feedback gegeben hat, werde ich versuchen, etwas Licht auf meine ursprüngliche Frage zu werfen, nachdem ich mit node.js assert und chai's Assert gearbeitet habe.

Die Antwort am Ende ist, dass sie funktional gleich sind. Der einzige Grund, warum Chai's Assert existiert, ist so, wenn Sie den Code lesen, können Sie ein besseres Verständnis der Tests bekommen, aber das ist es auch schon.

beispielsweise die Prüfung auf einen Nullwert mit Node.js:

assert (foo === null);

Und mit chai:

assert.isNull (foo);

Sie sind vollkommen äquivalent, und das Festhalten an node.js assert begrenzt Ihre Abhängigkeitsliste.

Answer 3

Haftungsausschluss: Ich bin der Autor des Moduls assertthat, auf das ich in dieser Antwort verweisen werde.

Grundsätzlich kann man alle Dinge mit Knoten ganz eigenen assert Modul erreichen, die Ihnen mit allen anderen Modulen tun können dort, wie Should.js, expect.js oder assertthat. Ihr Hauptunterschied ist die Art, wie Sie Ihre Absicht ausdrücken können.

Semantisch gesehen, die folgenden Codezeilen sind einander äquivalent:

assert.areEqual(foo, bar); 
foo.should.be.equal(bar); 
expect(foo).to.be(bar); 
assert.that(foo).is.EqualTo(bar); 

Syntaktisch gibt es zwei wesentliche Unterschiede:

Zuerst wird die should Syntax funktioniert nur, wenn foo nicht gleich zu null oder undefined, daher ist es schlechter als die anderen. Zweitens gibt es einen Unterschied in der Lesbarkeit: Währendliest wie natürliche Sprache, alle anderen nicht.

Schließlich ist Chai nur ein Wrapper um ein paar Assertion Module, um die Dinge für Sie einfacher zu machen.

Also, um eine lange Geschichte kurz zu machen: Nein, es gibt keinen technischen Grund, eine über die andere zu bevorzugen, aber die Lesbarkeit und null Kompatibilität kann Gründe sein.

Ich hoffe, das hilft :-)

PS: Natürlich intern, können sie unterschiedlich umgesetzt werden, so kann es beispielsweise subtile Dinge, wie Gleichheit geprüft wird.Wie ich im Disclaimer gesagt habe, bin ich der Autor der Behauptung, dass ich vielleicht voreingenommen bin, aber in den letzten Jahren hatte ich von Zeit zu Zeit die Situation, wo behauptet wurde, dass das zuverlässiger sei als die anderen, aber wie gesagt, kann ich sein voreingenommen.