Blog

JavaScript Days | Angular Days | React Days | HTML & CSS Days
Die großen Trainingsevents für JavaScript, Angular, React, HTML & CSS
18. - 21. März 2019 | München
17
Jul

Die beste Strategie fürs JavaScript-Testing: Mach’s einfach!

JavaScript-Testing: Wichtig und oft ignoriert. Dominik Ehrenberg und Sebastian Springer geben im Interview Tipps zur richtigen Toolauswahl und erklären, worauf man beim Testen von asynchronem Code in JavaScript achten muss.

Im Interview mit Mirko Hillert (Entwickler Akademie) beantworten Dominik Ehrenberg und Sebastian Springer auf den JavaScript Days Fragen zu Strategien und Patterns für das Testen von JavaScript-Code. Desweiteren erläutern sie, welche Hürden JavaScript-Entwicklern beim Testen begegnen, was man beim Testen von asynchronem Code beachtet werden muss und welches Tool unverzichtbar ist.

Mirko Hillert: Welche Strategien und Patterns gibt es für das Testen von JavaScript-Code?

Sebastian Springer: Wir haben die beste Strategie fürs JavaScript-Testing identifiziert: Mach’s einfach! Daneben gibt es noch zahlreiche andere Strategien wie zum Beispiel: Mach’s in möglichst kleinen Schritten und lass dich nicht von irgendwelchen Testfehlschlägen überraschen. Wenn du Testcode schreibst, dann schreib ihn so, als wäre es Produktivcode und wende die gleichen Qualitätsmetriken an.

Dominik Ehrenberg: Beim Testen ist es oft so, dass man nicht nur eine Ebene testet. Wir konzentrieren uns in unserem Workshop auf das Unittesting. Häufig kommt dann noch ein Integrationstesting und Oberflächentests dazu. Meine Erfahrung ist, dass es gerade bei der Verwendung eines CI-Systems sinnvoll ist, die aufeinander aufbauen zu lassen. Man führt also zuerst die Unittests durch. Wenn diese durchgelaufen sind, kann man die Integrationstests durchführen. Wenn die dann durchgelaufen sind, führ noch die End-To-End-Tests aus. Die laufen dann vielleicht 35 Minuten und man bekommt relativ schnell das Feedback, dass etwas nicht funktioniert.

Mirko Hillert: Welche Hürden begegnen JavaScript-Entwicklern beim Testen am häufigsten?

Dominik Ehrenberg: Die häufigste Hürde, die ich ausmache, ist, dass die Leute tatsächlich nicht wissen, wie sie DOM-Manipulation testen sollen. Die machen dann etwas auf der Website und es verändert sich etwas. Wie teste ich das eigentlich? Es fehlt ein bisschen der Ansatzpunkt und die Kenntnis über die Möglichkeiten, die es mittlerweile tatsächlich beim JavaScript-Testing gibt.

Sebastian Springer: Eine weitere Hürde ist, den ersten Schritt zu finden. Viele Frameworks wie zum Beispiel Angular oder auch React versuchen den Leuten das Testing einfacher zu machen und setzen dann auch schon Umgebungen dafür auf. Bei Angular zum Beispiel sind die Tests schon vorgeneriert. Man muss eigentlich nur noch das Testkommando eingeben und die Tests werden ausgeführt. Teilweise ist aber auch diese Hürde noch zu hoch. Ich verstehe das teilweise nicht und finde es sehr schade, weil Tests auch viel Sicherheit mit sich bringen. Sie müssen aber geschrieben werden, sonst hilft es nichts.

Dominik Ehrenberg: Eine zusätzliche Hürde, die überwunden werden muss, ist, dass die Tests in der Regel im Browser ausgeführt werden müssen. Da sind sich die Leute dann unsicher, wie das mit einem CI-System wie Jenkins und Co. funktioniert. Sie können sich dann nicht vorstellen, wie sie das ausführen können, obwohl auch das ein gelöstes Problem ist.

Mirko Hillert: Was muss man beim Testen von asynchronem Code beachten?

Sebastian Springer: Lass dich von deinen Tests nicht verarschen. Das haben wir in unserem Workshop schon gesehen. Bei asynchronen Tests wird der Test ausgeführt und wenn man nicht darauf achtet, wird die Überprüfung des Tests ausgeführt, wenn der Test schon vorbei ist. Das heißt, auch wenn der Test fehlschlägt ist alles grün. Dann ist eine Überprüfung ob true false ist, die ist dann erfolgreich. Das ist ziemlich fatal. So sind grüne Tests auch nicht immer erstrebenswert. Wir empfehlen unseren Teilnehmern dann auch, die Tests gezielt zu brechen. Sie sollen dann schauen, ob ein erwarteter Fehlschlag auch eintritt. Das ist der Tipp, den ich den Leuten immer gebe.

Dominik Ehrenberg: Die größte Herausforderung ist tatsächlich zu kontrollieren, wann der Test abgeschlossen ist. Bei Jasmine hatten wir den Fall, dass der Test vorbei ist, obwohl er eigentlich kaputt sein müsste. Bei manch anderem Testing-Framework wie Protractor kann es sein, dass der Test zwar durchgelaufen ist, also alles grün markiert ist, schlägt im Nachhinein fehl und bricht dann Tests, die daraufhin laufen. Einfach diese Kontrolle zu haben, wann der Test vorbei ist, darauf kommt es beim asynchronen Testen an.

Mirko Hillert: Welche Rolle spielen die Browsertools für das Testen von JavaScript?

Sebastian Springer: Browsertools gibt es in dem Sinne ja nicht sonderlich viele. Es gibt den Debugger, der recht hilfreich ist, wenn man auf Fehlersuche gehen muss. Viel hilfreicher jedoch sind die ganzen Testingtools, die die Testframeworks an sich mitbringen, wie zum Beispiel Code Coverage Reports oder irgendwelche Plug-ins, mit denen sich Asynchronität oder Zeiten besser testen lassen. So ein Testframework bringt einen Grundsatz an Hilfsmitteln mit und die werden durch Plug-ins und Erweiterungen erweitert, können dann benutzt werden und machen das Testing viel komfortabler.

Mirko Hillert: Welche Arten von Testtools gibt es grundsätzlich?

Sebastian Springer: Das sind im Prinzip diese Plug-ins und Erweiterungen, die ich schon erwähnt habe. Es gibt eigentlich für jede Problemstellung, vor der du stehst, ein Tool, das dir das Leben erleichtert. Das Gute ist, dass wir uns in einem Feld bewegen, in dem sich viele schlaue Menschen bewegen, die dann Probleme lösen. Man muss also nur gut im Googlen sein, die richtigen Tools zusammenstecken und dann funktioniert es. Ein Modulsystem, ein TypeScript sind also keine Hürden mehr. Das sind alles gelöste Probleme, man muss nur nach der richtigen Lösung suchen.

Mirko Hillert: Bei welchen Aufgaben unterstützt Jasmine Entwickler?

Sebastian Springer: Beim Test-Schreiben. Jasmine an sich ist wieder ein Basisframework und bietet dir als Entwickler eine solide Basis. Es lässt sich gut erweitern, ist relativ performant und hat eine Syntax, die auch andere Testtools und -frameworks übernehmen. Das heißt, ein Umstieg in ein anderes Framework wie z. B. Mocha ist nicht tragisch. Es ist ein universelles Tool. Wenn man das in Projekten einsetzt, macht man damit nichts falsch.

Dominik Ehrenberg: Das Gute an Jasmine ist zudem, dass es nicht nur das Testframework an sich ist, sondern üblicherweise auch noch der Runner mit dabei ist. Sodass ich sagen kann: „Das sind meine Tests, führ die aus.“ Wenn ich dann noch so etwas wie Karma oben drauf setzte, was an sich nichts anderes tut als Jasmine auszuführen, ist es relativ einfach, all dies automatisiert auf einem Jenkins auszuführen.

Mirko Hillert: Welches Tool ist eurer Meinung nach unverzichtbar für das Testen von JavaScript-Code?

Sebastian Springer: Die richtige Kombination aus Tools, um die Probleme zu lösen. Wenn ich mich in einer Angular-Umgebung befinde, dann brauche ich Jasmine und einen Protractor. Wenn ich eine React-Applikation testen möchte, dann nutze ich das Jest-Framework. Man muss also immer das richtige Tool für die richtige Umgebung kennen. Serverseitig auf Node.js würde ich eher zu Mocha, Chai oder expect.js tendieren. Man muss also schauen, was man für die jeweilige Umgebung nutzen möchte.

Dominik Ehrenberg: Ein wichtiger Punkt ist auch, dass man das immer automatisiert bekommt. Die Tests sind relativ nutzlos, wenn sie nur lokal ausgeführt werden. Im Zweifelsfall führt man sie dann nämlich nicht aus und es ist trotzdem kaputt. Es sollte also wirklich geschaut werden, ob sich das Vorhandene automatisieren und automatisiert auswerten lässt. Bekomme ich eine vernünftige Anzeige in meinem Jenkins mit den Tools, die ich verwende?

Sebastian Springer: Und die Tests müssen natürlich schnell laufen. Kein Mensch hat Lust, zehn Minuten auf seine Tests zu warten. Also automatisiert und schnell.

Mirko Hillert: Sebastian, Dominik, vielen Dank für das Interview.

 

Interviewt von: Mirko Hillert

Mirko Hillert verantwortet seit 2007 als Leiter der Entwickler Akademie den Trainingsbereich bei Software & Support Media. Er studierte Betriebswirtschaft an der Westsächsischen Hochschule Zwickau und der Universidad Valencia sowie Marketing an der Westfälischen Wilhelms-Universität Münster. Als ehemaliger Dozent und Ausbilder für Managementprozesse treibt er seit vielen Jahren die fundierte Aus- und Weiterbildung von Entwicklern und Softwarearchitekten im IT-Markt voran, unter anderem mit innovativen Eventformaten und hochwertigen Trainingsinhalten.

Immer auf dem Laufenden bleiben! Alle News & Updates: