JavaScript testgetrieben entwickeln mit QUnit
Kommentare

Das Mockup ist recht simpel. Es hält im Hintergrund ein Array mit To-do-Listen-Namen, und wenn eine To-do-Liste angefordert wird, wird eine neue Instanz mit fünf Einträgen erzeugt (Listing 6).
Listing

Das Mockup ist recht simpel. Es hält im Hintergrund ein Array mit To-do-Listen-Namen, und wenn eine To-do-Liste angefordert wird, wird eine neue Instanz mit fünf Einträgen erzeugt (Listing 6).

Listing 6: Persistenz
function Persistence(){
    var listNames = ["Allgemein","Arbeit","Familie","Artikel","Karriere"];
    var todoLists = [];
    
    this.getTodoList = function(name){
        var todoList = todoLists[name];
        if(todoList == undefined){
            todoList = new TodoList(name);
            for(var i = 0;i

Bisher haben wir alle Tests mit der Annahme ok durchgeführt, was uns auch zum Ziel geführt hat. Aber gerade, wenn es sich bei den Annahmen um Gleichheitsannahmen handelt, gibt es eine bessere Funktion, die man nutzen sollte: die equal-Funktion mit folgender Syntax:

equal(aktuellerWert, erwarteterWert, Nachricht)

Das sieht jetzt gar nicht so viel anders aus als die Syntax des bisher verwendeten ok, aber wenn wir uns die Ausgabe zu den beiden fehlschlagenden Assertions aus Listing 7 in Abbildung 6 ansehen, wird recht gut deutlich, wie viel aussagekräftiger die Fehlermeldung bei equal ist.

Listing 7
...
equal(names.length , 6, 
      "Es sind 5 todoListen Namen im persistenceMock hinterlegt");
ok(names.length == 6, 
   "Es sind 5 todoListen Namen im persistenceMock hinterlegt");
...
Abb. 6: Unterschied ok- und equal-Annahmen

Wenn es in einem Unit Test sinnvoll ist, komplexe Objektstrukturen oder Arrays auf Gleichheit zu prüfen, dann gibt es auch für diesen Fall die richtige Annahmefunktion. Sie heißt deepEqual und hat die gleichen Parameter wie das einfache equal. Eine Möglichkeit der Verwendung mit Arrays findet sich im Listing 8. Hier wird das zurückgelieferte Array der To-do-Listen-Namen gegen das gesamte Array expectedNames getestet.

Listing 8: deep Equal
...
    var expectedNames = ["Allgemein","Arbeit","Familie","Artikel","Karriere"];
    var names = persistence.getTodoListNames();
...
    deepEqual(names, expectedNames, "ergebnisarray muss enthalten "     +expectedNames)
...

Im Fehlerfall ist die Auswertung dann noch genauer und macht das Auffinden des Fehlers geradezu zu einem Kinderspiel. Im letzten Abschnitt möchte ich noch auf das Testen von DOM-Manipulationen eingehen. Wie bereits erwähnt, wird im Beispiel zur DOM-Manipulation auf die jQuery-Bibliothek zurückgegriffen, wodurch der Quellcode übersichtlich bleibt. Um DOM-Manipulationen im Unit Test testen zu können, müssen wir uns zuerst einmal manipulierbaren Webseiteninhalt in unserer unittest.html erzeugen. Listing 9 zeigt die notwendigen Änderungen.

Listing 9: Änderungen an „unittest.html“
  ...
  
  ...
  
...

TodoListentitel

listitem1
listitem2
...
...

Alle Funktionen zur Manipulation der Darstellung der To-do-Liste befinden sich in der JavaScript-Datei productioncode.js. Im Test in Listing 10 wird zuerst über den Aufruf der Funktion removeEvenOddLayout() die Zuordnung der Einträge zu den entsprechenden Style-Klassen aufgehoben. Mit den beiden folgenden jQuery-Aufrufen wird die Anzahl der Items der jeweiligen Klassen in Variablen gespeichert, um sie dann anschließend auf ihren Wert (0) zu testen.

Listing 10: DOM-Manipulation
//methodenaufruf
    removeEvenOddLayout();

    //daten sammeln
    var even_items = $(".item_even").length;
    var odd_items = $(".item_odd").length;

    //Auswertung der Annahmen
    equal(even_items,0, "Nach entfernen der css-Klassen keine even Items mehr vorhanden.");
    equal(odd_items ,0, "Nach entfernen der css-Klassen keine odd Items mehr vorhanden.");
Fazit

Es gäbe noch viele interessante Facetten des JavaScript Unit Testings zu beleuchten. Auch gibt es noch einige Themen im Zusammenhang mit QUnit, die eine genauere Betrachtung verdienten. Beispielsweise lassen sich die Tests auch zu Modulen zusammenfassen, und durch URL-Parameter ließe sich steuern, welche Tests aktuell auszuführen sind. Diese Themen würden aber den Rahmen dieses Artikels sprengen. Ich hoffe, einen guten Einblick in die Möglichkeiten des Unit Testings in JavaScript mit QUnit gegeben zu haben und freue mich, möglicherweise in einem fortführenden Artikel, noch andere Facetten behandeln zu können.

Marco Dierenfeldt ist als Senior Consultant und Coach bei der Saxonia Systems AG tätig. Seine ersten Erfahrungen im Gestalten von Webseiten machte er Mitte der 90er Jahre und verwendete 1996 zum ersten Mal JavaScript für Effekte auf seinen Webseiten.
Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -