Ausführliche Erläuterung der ersten Schritte mit dem NodeJS-Testframework Mokka

Dieser Artikel stellt kurz die Installation und einfache Verwendung von Mocha vor, dem am häufigsten verwendeten Testframework in NodeJS. Es unterstützt die Ausführung von Javascript-Codetests direkt im Browser. Es wird hier jedem empfohlen

Das am häufigsten verwendete Testframework in NodeJS ist wahrscheinlich Mokka. Es unterstützt eine Vielzahl von Node-Assertion-Bibliotheken, unterstützt sowohl asynchrone als auch synchrone Tests, unterstützt mehrere Möglichkeiten zum Exportieren von Ergebnissen und unterstützt auch die Ausführung von Javascript-Codetests direkt im Browser.

Die meisten Beispiele in diesem Artikel sind von den Beispielen auf der offiziellen Website abgeleitet, und einige Beispiele wurden basierend auf Bedürfnissen oder meinen eigenen Gefühlen modifiziert. Weitere Informationen finden Sie auf der offiziellen Website: Mocha auf Github

Installation:

Wenn Sie nodejs v0.10 und npm erfolgreich installiert haben, führen Sie den folgenden Befehl aus.

# npm install -g mocha

P.s. Bitte beachten Sie, dass die NodeJS-Version in der apt-Quelle älter ist und einige Module nicht unterstützt werden. Bitte installieren Sie den Quellcode von der offiziellen NodeJS-Website .

Erster Schritt zu Mokka:

Das Folgende ist das einfachste Mokka-Beispiel:

var assert = require("assert");
describe('Array', function(){
 describe('#indexOf()', function(){
  it('should return -1 when the value is not present', function(){
     assert.equal(-1, [1,2,3].indexOf(5));
   assert.equal(-1, [1,2,3].indexOf(0));
 })
 })
});

describe (moduleName, testDetails) Wie aus dem Obigen ersichtlich ist Code und Beschreibung können verschachtelt sein. Beispielsweise können die beiden im obigen Code verschachtelten Beschreibungen als Wunsch des Testers verstanden werden, das Submodul #indexOf() unter dem Array-Modul zu testen. module_name kann beiläufig gewählt werden, der Schlüssel liegt darin, es verständlich zu machen.
it (info, function) Die spezifische Testanweisung wird in die Callback-Funktion eingefügt. Im Allgemeinen schreibt infostring einen kurzen Satz der erwarteten korrekten Ausgabe Beschreibung. Wenn der Test im it-Block fehlschlägt, druckt die Konsole die detaillierten Informationen aus. Im Allgemeinen beginnt die Ausgabe mit dem Modulnamen der äußersten Beschreibung (was als Pfad, rekursive Kette oder Rückrufkette verstanden werden kann) und gibt schließlich Informationen aus, die darauf hinweisen, dass der erwartete Informationsinhalt nicht erfüllt wurde. Es entspricht einer tatsächlichen Testfall
assert.equal (exp1, exp2)-Behauptung, um zu bestimmen, ob das Ergebnis von exp1 gleich exp2 ist. Das hier angenommene Gleichheitsurteil ist == anstelle von ===. Das heißt, „sert.equal(1, ‚1‘)“ wird als „True“ betrachtet. Dies ist nur eine Assertionsform von Assert.js in NodeJS. Die ebenfalls häufig verwendeten Should.js werden unten erwähnt.
Wenn exp1 und exp2 beide Strings sind und beim String-Vergleich ein Fehler auftritt, verwendet die Konsole Farbe, um die verschiedenen Teile zu markieren.

Asynchron

Der Code im ersten Schritt ist offensichtlich synchroner Code. Was sollen wir also mit asynchronem Code tun? Es ist ganz einfach: Fügen Sie done() zu Ihrer tiefsten Rückruffunktion hinzu, um das Ende anzuzeigen.

fs = require('fs');
describe('File', function(){
 describe('#readFile()', function(){
   it('should read test.ls without error', function(done){
   fs.readFile('test.ls', function(err){
  if (err) throw err;
  done();
  });
 })
 })
})

done ()0c6dc11e160d3b678d68754cc175188a Gemäß den Gewohnheiten der Wasserfallprogrammierung bedeutet der Name done den tiefsten Punkt Ihres Rückrufs, also das Ende des Schreibens verschachtelter Rückruffunktionen. Aber für die Rückrufkette bedeutet „fertig“ eigentlich, Mocha anzuweisen, von hier aus mit dem Testen zu beginnen und Schicht für Schicht zurückzurufen.

Der obige Beispielcode dient zum Testdurchlauf. Wir versuchen, test.ls in das nicht vorhandene test.as zu ändern. Der spezifische Fehlerort wird zurückgegeben.

Hier stellt sich möglicherweise eine Frage: Wenn ich zwei asynchrone Funktionen (zwei gegabelte Rückrufketten) habe, wo soll ich done() hinzufügen? Tatsächlich sollten zu diesem Zeitpunkt nicht zwei Funktionen in einem it getestet werden. Tatsächlich kann done nur einmal in einem it aufgerufen werden. Wenn Sie done mehrmals aufrufen, gibt Mocha einen Fehler aus. Es sollte also etwa so aussehen:

fs = require('fs');
describe('File', function(){
 describe('#readFile()', function(){
   it('should read test.ls without error', function(done){
   fs.readFile('test.ls', function(err){
  if (err) throw err;
  done();
  });
 })
   it('should read test.js without error', function(done){
   fs.readFile('test.js', function(err){
  if (err) throw err;
  done();
  });
 })
 })
})

Ausstehend

Das heißt, Sie lassen die Testdetails weg und behalten nur den Funktionskörper bei. Dies ist im Allgemeinen auf Situationen anwendbar, in denen beispielsweise die für das Testen des Frameworks verantwortliche Person das Framework geschrieben hat und die Teammitglieder die Details implementieren lässt, oder wenn die Testdetails nicht vollständig korrekt implementiert wurden und zuerst mit Anmerkungen versehen werden sollten, um eine Beeinträchtigung der gesamten Testsituation zu vermeiden . In diesem Fall führt Mocha standardmäßig den Testdurchlauf durch.
Es funktioniert ein bisschen wie Pythons Pass.

describe('Array', function(){
 describe('#indexOf()', function(){
  it('should return -1 when the value is not present', function(){
 })
 })
});

Exklusiv && Inklusive

ist eigentlich leicht zu verstehen und entspricht jeweils den Funktionen „Einzig“ und „Überspringen“.

fs = require('fs');
describe('File', function(){
 describe('#readFile()', function(){
   it.skip('should read test.ls without error', function(done){
   fs.readFile('test.ls', function(err){
  if (err) throw err;
  done();
  });
 })
   it('should read test.js without error', function(done){
 })
 })
})

Mit dem obigen Code wird nur ein Test abgeschlossen, nur der einzige wird ausgeführt und der andere wird ignoriert. In jeder Funktion kann es nur eine geben. Wenn it.skip, wird dieser Fall ignoriert.

Nur ​​Teilen und Überspringen haben keine praktische Bedeutung, da die Funktion „Nur“ das Überspringen blockiert.

fs = require('fs');
describe('File', function(){
 describe('#readFile()', function(){
   it.skip('should read test.ls without error', function(done){
   fs.readFile('test.as', function(err){
  if (err) throw err;
  done();
  });
 })
   it('should read test.js without error', function(done){
 })
 })
})

Obwohl test.as im obigen Code nicht vorhanden ist, wird der Test abgeschlossen aufgrund des Überspringens dennoch angezeigt.

Vorher & Nachher

Vorher und Nachher werden häufig bei Unit-Tests verwendet. mocha bietet auch beforeEach() und afterEach().
Der Einfachheit halber wird hier in Livescript ausgedrückt: !-> kann als function(){} verstanden werden. Es ist nicht erforderlich, die Details sorgfältig zu lesen. Sie müssen lediglich verstehen, wie diese Funktionen über das Framework verwendet werden.

require! assert
require! fs
can = it


describe 'Array', !->
 beforeEach !->
 console.log 'beforeEach Array'

 before !->
 console.log 'before Array'
 
 before !->
 console.log 'before Array second time'

 after !->
 console.log 'after Array'

 describe '#indexOf()', !->
 can 'should return -1 when the value is not present', !->
  assert.equal -1, [1,2,3].indexOf 0
 can 'should return 1 when the value is not present', !->

 describe 'File', !->

 beforeEach !->
  console.log 'beforeEach file test!'

 afterEach !->
  console.log 'afterEach File test!'

 describe '#readFile()', !->
  can 'should read test.ls without error', !(done)->
  fs.readFile 'test.ls', !(err)->
   if err
   throw err
   done!
  can 'should read test.js without error', !(done)->
  fs.readFile 'test.js', !(err)->
   if err
   throw err
   done!

Aus den Ergebnissen geht hervor (die Verwendung von after ist die gleiche wie zuvor),

beforeEach wird auf alle Unterfälle unter der aktuellen Beschreibung wirksam.
Für die Vorher- und Nachher-Codes ist keine besondere Reihenfolge erforderlich.
Es können mehrere Befores unter derselben Beschreibung vorhanden sein, und die Ausführungsreihenfolge ist dieselbe wie die Codereihenfolge.
Die Ausführungsreihenfolge unter derselben Beschreibung ist before, beforeEach, afterEach, after
Wenn es mehrere Befores hat, beginnt die Ausführungsreihenfolge beim Before der äußersten Beschreibung, und der Rest ist gleich.

Testgetriebene Entwicklung (TDD)

mocha默认的模式是Behavior Driven Develop (BDD)，要想执行TDD的test的时候需要加上参数，如

mocha -u tdd test.js

前文所讲的describe, it, before, after等都属于BDD的范畴，对于TDD，我们用suite, test, setup, teardown。样例代码如下:

suite 'Array', !->
 setup !->
 console.log 'setup'

 teardown !->
 console.log 'teardown'

 suite '#indexOf()', !->
 test 'should return -1 when not present', !->
  assert.equal -1, [1,2,3].indexOf 4

Das obige ist der detaillierte Inhalt vonAusführliche Erläuterung der ersten Schritte mit dem NodeJS-Testframework Mokka. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!