Tests auf dem Server

Test-Frameworks wie Buster.JS bieten die Möglichkeit, Anwendungen mit JavaScript-Code umfassend zu testen. Wenn das Entwicklungsziel die ablauffähige JavaScript-Software im Browser ist, kann als Framework "JsTestDriver" eingesetzt werden. Will man JavaScript-Software jedoch auch auf dem Server in Zusammenhang mit der Open-Source-Plattform "Node.js" ausführen, bietet "Buster.JS" einen vielversprechenden Ansatz. Das Tool liefert eine Testumgebung, in der JavaScript-Code in einer isolierten Umgebung durch unterschiedliche Browser automatisiert getestet wird. Dadurch erreicht man kurze Turn-around-Zeiten beginnend bei der Testerstellung über die Programmierung bis hin zur Ausführung.

Softwareentwickler schreiben üblicherweise Tests und starten dann einen Testserver, an dem sich die gewünschten, unterschiedlichen Browser oder Browserversionen anmelden. Der Testserver liefert eine Testkomponente an die Browser aus. Anschließend liefert das Framework ein Protokoll. Der Testdurchlauf lässt sich automatisch auswerten. Das gesamte Verfahren reiht sich in die Kette der automatisierten Entwicklungs- und Testwerkzeuge ein. Somit ist eine permanente Integration von Buster.JS in die Entwicklungsumgebung möglich.

Installation von Buster.JS

Buster.JS lässt sich relativ einfach installieren und konfigurieren. Da das Testprogramm ein Node.js-Modul ist, wird es zum Beispiel unter Linux über den Node Paket Manager mittels "npm install -g buster" installiert. Das klappt mittlerweile auch unter Windows - allerdings hakt Buster.JS hier an manchen Stellen. Eine vollständige Unterstützung ist erst für die Version 1.0 geplant. Nach erfolgreicher Installation muss Buster.JS mitgeteilt werden, wo sich die Quell- und Testdateien befinden und in welcher Umgebung die Tests ausgeführt werden sollen - ob im Browser oder mit Node.js. Die Konfiguration erfolgt in JavaScript.

Bei Buster.JS wird zwischen einer Konfigurationsdatei und den eigentlichen Konfigurationen (Konfigurationsgruppen) unterschieden. Eine Konfigurationsdatei kann dabei mehrere Konfigurationen enthalten. Das Modul exportiert deshalb eine Anordnung (Array) von Konfigurationsobjekten. Diese können sich gegenseitig sogar erweitern. Das ist ein Vorteil, der später genutzt werden kann, um Tests sowohl im Browser als auch mit Node.js auszuführen.

Fazit: JavaScript berücksichtigen

Ein Trugschluss ist, dass nur wenig JavaScript in Anwendungen vorhanden ist und deshalb ein Testbereich ignoriert werden kann. Auch kleine JavaScript-Snippets können fehlerhaft sein und sich auf den verschiedenen Plattformen unterschiedlich verhalten. Es lohnt sich darüber nachzudenken, wie man als Entwickler mit bestehenden, sich in Wartung und Weiterentwicklung befindlichen Anwendungen umgehen soll. Sie enthalten mit zunehmender Lebensdauer mehr und mehr gewachsene Strukturen. Aus Kostengründen müssen Anwendungsentwickler bei Design-Entscheidungen häufig Kompromisse eingehen, ohne vorab an unerwünschte Auswüchse zu denken. Die Neigung zu diesen Kompromissen ist umso höher, je unklarer das Anwendungsverständnis ist und je weniger sicher ein Entwickler sein kann, ob die von ihm vorgenommenen Veränderungen einen negativen Effekt haben.

Hier schließt sich der Kreis: Liegen nach der Entwicklung Tests vor, kann das Re-Engineering mit größerem Vertrauen in die Anwendung ausgeführt werden. Das beschleunigt den Prozess und sichert die Qualität. Durch den Einsatz von modernen Frameworks wie Buster.JS lassen sich weite Teile der Anwendungsentwicklung abdecken. So sind Softwareentwickler in der Lage, die Qualität der Software zu verbessern. (tw)