JavaScript Unit Testing mit WebStorm Schritt für Schritt

JavaScript tut Not. Es hilft halt nichts. Lieber würde ich mich zwar mehr mit F# beschäftigen, doch dringender scheint mir JavaScript-Fingerfertigkeit. Denn mit JavaScript kann ich meine Reichweite vergrößern in Richtung Web und Mobile. Bisher bin ich ja eher der “Desktop GUI Guy” ;-) Und mit JavaScript kann ich coole Entwicklungen schneller mitmachen im Bereich Backend, z.B. node.js oder Cloud APIs. .NET Bindings werden da ja eher stiefmütterlich behandelt.

F# brächte mir zwar Vorteile bei der Strukturierung von Geschäftslogik. Doch da bin ich weniger Unzufrieden mit C# als bei Reichweite und Modernität.

Also mehr JavaScript. Hier ein bisschen, da ein bisschen. Vor allem aber auch gern testgetrieben.

Als Entwicklungsumgebung habe ich mir mal WebStorm von JetBrains angeschafft. Das war sehr preisgünstig beim letzten Cyber Monday und schien ordentlich.

Damit geht auch testgetriebene Entwicklung – nur ist die nicht so einfach zu starten, wie bei VS mit ReSharper. Deshalb hier ein Spickzettel zunächst einmal für mich selbst:

1. Verzeichnisse einrichten: In einem WebStorm Projekt zwei Verzeichnisse einrichten, eines für den Produktionscode, eines für Testcode.

Wie die Verzeichnisse heißen, ist eigentlich egal. Ihre Namen müssen nur korrekt im nächsten Schritt referenziert werden.

2. Konfigurationsdatei angelegen: Bei .NET findet ein Testrunner die Tests automatisch in den Assemblies eines Projektes. Bei JavaScript muss man dafür jedoch eine Konfigurationsdatei anlegen. (Zumindest für den JavaScript Test-Driver, der mit WebStorm ausgeliefert wird.) Der Name der Datei ist nicht so wichtig, die Extension muss allerdings .jstd sein:

Die Konfiguration ist simpel: Sie enthält die Adresse des Testrunners, der in einem Browser läuft. Und sie listet die Quellen für Produktionscode (load:) und Tests (test:):

server: http://localhost:9876

load:
  - src/*.js

test:
  - tests/*.js

Die Quellen nehmen Bezug auf die oben angelegten Verzeichnisse.

3. Tests werden im Testverzeichnis angelegt. Am besten zur weiteren Konfiguration des Testframeworks einen Probeweisen Test anlegen. Im ersten Schritt sieht der nur so aus:

Wichtig ist, dass angeboten wird, die Bibliotheksdateien des Testframework zu laden. Das sollte mit dem Shortcut getan werden. Dann sieht das Projekt so aus:

Durch die Referenzierung dieser Dateien steht für Tests Intellisense zur Verfügung:

Achtung: Tests müssen den Präfix “Test” haben!

4. Leider läuft der Probetest jetzt noch nicht einfach so. Es muss erst noch eine Laufzeitkonfiguration für das Projekt angelegt werden:

Hier wird die .jstd-Datei referenziert! Und der Name der Konfiguration taucht dann im Run-Menü auf:

5. Jetzt den Probetest ausführen lassen. Falls das nicht funktioniert, läuft der Testserver wahrscheinlich nicht. Der wird im Browser gehostet. Gestartet werden kann er über die IDE:

Durch Klick auf ein Browser-Icon wird der Testrunner-Server als Seite im Browser geöffnet:

Und nun – Wunder der Technik! – wird auch der Test über Run ausgeführt. Die IDE erstrahlt in frischem Grün:

 

Das war´s. Jetzt, da ich das Setup nochmal Schritt für Schritt durchlaufen bin, ist es gar nicht mehr so undurchsichtig. Aber wer weiß… Wenn ich mal wieder längere Zeit JavaScript nicht in die Hand nehmen sollte, hilft mir diese Erläuterung bestimmt, schneller wieder reinzukommen.

Und es bewahrheitet sich der alte Spruch, dass man durch Lehren, also Erklären, am besten lernt.