Seite 4: Exkurs

Inhaltsverzeichnis

Mocha konfigurieren

Mocha kennt eine Vielzahl an Kommandozeilenparametern, von denen man jedoch nur einige wenige regelmäßig benötigt. Es empfiehlt sich aus naheliegenden Gründen, eine individuelle Datei mocha.opts als Vorlage anzufertigen, die für jede Anwendung als Basis dienen kann.

• --recursive aktiviert die Suche nach JavaScript-Dateien auch in Unterverzeichnissen des test-Verzeichnisses. Auf diese Weise lassen sich Testdateien weitaus übersichtlicher strukturieren.
• --reporters listet alle verfügbaren Ausgabeformate von Mocha einschließlich einer kurzen Beschreibung auf.
• --reporter aktiviert eines dieser Ausgabeformate, wobei der Name des gewünschten Ausgabeformats dem Parameter als Option zu übergeben ist.
• --interfaces listet alle verfügbaren Teststile von Mocha auf, wie den TDD- und den BDD-Stil.
• --ui aktiviert einen der Teststile, wobei auch hier wieder der Name des gewünschten Stils übergeben werden muss. Geschieht das nicht, verwendet Mocha standardmäßig den BDD-Stil.
• --bail aktiviert den Abbruch der Testausführung nach der ersten fehlgeschlagenen Überprüfung. Wird dieser Parameter nicht angegeben, führt Mocha alle Tests aus und listet die fehlgeschlagenender Reihe nach auf.
• --grep schränkt die Menge der auszuführenden Tests auf jene ein, deren Name ein bestimmtes Muster enthält. Dieses ist dem Parameter als Option zu übergeben.
• --slow und --timeout legen die Grenzwerte für langsame beziehungsweise hängen gebliebene Tests in Millisekunden fest. Beiden Parametern ist der jeweils gewünschte Wert als Option zu übergeben.

Eine typische Vorlage für die Datei mocha.opts könnte also beispielsweise den folgenden Code enthalten:

--recursive
--ui tdd
--reporter spec
--bail

assert, should & Co.

Außer dem in Node.js von Haus aus integrierten assert-Modul gibt es noch weitere, die sich durch eine andere Syntax und mehr Komfort abheben:

should stammt wie Mocha und Express von TJ Holowaychuk. Die von diesem Modul favorisierte Syntax passt perfekt zum BDD-Stil, den Mocha von Haus aus verwendet. Da in diesem das Verb "should" für die Namensgebung der Tests eine bedeutende Rollespielt, liegt es nahe, den Code ähnlich zu schreiben:

actual.should.eql(expected);
 

Der wesentliche Nachteil von should ist, dass es aufgrund der verwendeten Syntax zu Laufzeitfehlern kommt, wenn die Variable actual den Wert undefined enthält: Dann versucht should, auf eine nicht existente Eigenschaft zuzugreifen, was unweigerlich fehlschlägt – allerdings auf nicht kontrollierte Art.

Diesen Nachteil umgeht das Modul expect, indem es eine andere Syntax verwendet. Da bei dieser die Variable actual lediglich als Parameter einer Funktion verwendet wird, kann der zuvor beschriebene Fehler nicht auftreten:

expect(actual).to.eql(expected);
 

Einen ganz anderen Ansatz verfolgt das Modul node-assertthat, das vom Autor des vorliegenden Artikels stammt. Es verwendet die selbe Syntax wie das Testframework NUnit für .NET und legt Wert auf eine gute Lesbarkeit des Codes:

assert.that(actual, is.equalTo(expected));


(jul)