Mirko Hillert: Elmar, du hältst den Workshop „Test-Driven mit React“ hier auf den JavaScript Days, zudem bist du verantwortlich für das Programm. Oft haben Entwickler keine Zeit für tiefgehende Analysen und umfangreiche Tests. Wieso ist das deiner Meinung nach eine gefährliche Einstellung?

Elmar Burke: Oft fehlt gerade am Anfang der Projekte die Zeit, und die Projektleitung möchte schnelle Erfolge sehen. Da halten Tests natürlich auf. Tests sind Code, der zunächst nichts zur Problemlösung des eigentlichen Projekts beiträgt. Dabei sind Tests im späteren Prozess des Projekts eine immense Hilfe. Wenn man dann in der letzten Minute vor dem Livegang etwas verändert, fallen schnell mal Sachen um und gehen kaputt – genau dann zahlen sich Tests aus. Natürlich wird man sich dadurch niemals zwei Wochen Entwicklungszeit sparen, dennoch kann man sich am Ende sicherer fühlen, wenn man alle möglichen Tests genutzt hat.

Mirko Hillert: Ist es tatsächlich so, dass man keine Zeit hat? Wieso grassiert diese Einstellung bei Entwicklern so häufig?

Elmar Burke: Keine Zeit ist in der Entwicklung sowieso immer ein Problem. Man will immer schnellstmöglich die Problemlösung fertigbekommen. Ganz am Anfang ist es meist so, dass schnell irgendwo ein Bootstrap hingebaut wird. Es wird schnell Code geschrieben, sodass irgendwo etwas zu sehen ist. Dafür schreibt man dann meist keine Tests. Dann kommt aber jemand und sagt: „Hey, du hast das doch so schnell gemacht. Kannst du das nicht noch mal in der selben Geschwindigkeit machen und dies und das einfügen?“ Dann fallen die Tests hinten weg, bis eben Sachen kaputt gehen und man bereut, keine Tests gehabt zu haben.

Mirko Hillert: Als potentielle Lösung stellst du dem den Ansatz des Test-driven Development gegenüber. Kannst du die Grundsätze dieses Ansatzes kurz erläutern?

Elmar Burke: Im Test-driven Development beginnt alles mit dem Schreiben des Tests. Das kann dann ein Unit-, Functional, Integration oder End-to-end-Test sein. Dort wird dann definiert, was überhaupt die Anforderung ist. Diese liegt textuell irgendwo im Jira oder Trello vor und wird dann in Code geschrieben. Dieser Code wird später nur noch valide gemacht, sodass die Tests erfolgreich sind. Danach kann der Code ganz sauber umgebaut werden. Die Anforderung wurde nämlich einmal aufgeschrieben und man weiß, dass sie immer getroffen werden kann. Das ist im Grunde genommen Test-driven Development ganz grob zusammengefasst.

Mirko Hillert: Was genau versteht man unter einem sinnvollen Test?

Elmar Burke: Es gibt Tests, die Programmlogik testen und es gibt Tests, die testen Konfiguration. Tests, die Konfiguration testen, sind absolut sinnlos. Wenn man ein Element hat und möchte, dass es eine Überschrift der ersten Ordnung ist, also ein h1-Element, und dann testet, ob es ein h1-Element ist, dann testet man keine Logik. Das macht keinen Sinn. Spätestens wenn man damit Operationen macht, darauf überprüfen möchte, ob die richtigen Elemente zurückgegeben werden und Berechnungen stattfinden, dann sind das sinnvolle Tests. Algorithmen kann man wunderbar testen, aber eben keine Konfigurationen.

Mirko Hillert: Welche Vorteile ergeben sich aus einem guten Testing?

Elmar Burke: Ein gutes Testing hilft, Probleme zu finden, von denen man nicht weiß, dass man sie überhaupt hat. Es gibt das altbekannte SOLID-Prinzip, das jeden Informatikstudenten im Studium irgendwann mal gequält hat. Das ist unter anderem Single Responsibility. Diese Single Responsibility ist das Loslösen von ganz groben Segmenten. Mit Unittest kann man dieses SOLID-Prinzip enforcen, dass es wirklich umgesetzt werden muss. Denn ohne das SOLID-Prinzip ist es quasi nicht möglich, gute Unittests zu schreiben. Dadurch baut man bessere Entwurfspatterns in seine Anwendung ein, wodurch die Anwendung später von jedem besser verstanden wird. Ein weiterer Vorteil ist, dass Tests eine Art von Dokumentation von allen Fällen, an die man gedacht hat, sind. „Tests sind Dokumentationen“ ist häufig ein Schlagwort, das nie so ganz stimmt, da Code kann nie eine wirkliche Dokumentation ersetzen kann. Es kann aber aufzeigen, an welche Fälle der Entwickler gedacht hat, während er eine spezielle Funktion oder Komponente entwickelt hat.

Mirko Hillert: Warum passt TDD so gut mit React zusammen?

Elmar Burke: React ist von Haus aus ein sehr funktionales Framework beziehungsweise eine funktionale Library. Dieses funktionale Entwurfspattern macht Testen sehr einfach. Wenn man immer die gleichen Eingabeparameter liefert, bekommt man immer die gleichen Ausgabeparameter. Das ist genau das Vorhersagbare, das man für Unittests braucht. Wenn man Functional Tests machen möchte, den Browser also mit in seine Tests einbeziehen möchte, dann funktioniert das ebenfalls gut mit React. Das läuft nämlich einfach nur im Browser und man kann dort mit anderen Test-Librabries helfen, diese Dynamik einzufangen. Gerade beim Functional Programming, das was React umsetzt, ist es sehr vorhersagbar, was Komponenten machen, und es lässt sich sehr gut in Schritten aufschreiben. Diese Schritte kann man dann in seinen Test Cases – seien es Unit-Tests, End-to-end- oder Functional Tests – ganz gut abdecken.

Mirko Hillert: Elmar, 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.