Buch-Rezension zu "Continuous Testing"

"Continuous Testing – with Ruby, Rails, and JavaScript" von Ben Rady und Rod Coffin erschien im Juni 2011 bei The Pragmatic Programmers. Continuous Testing geht noch einen Schritt weiter als Test Driven Development und versucht die Feedback-Schlaufe von Red-Green-Refactor noch mehr zu verkürzen.

[Hinweis: Ich habe dieses Buch über die .Net User Group Bern erhalten, die am User Group Programm von O’Reilly teilnimmt. Wie immer wenn ich über Bücher blogge schreibe ich was mir daran gefällt und was nicht. Dies mache ich unabhängig davon ob ich ein Rezensionsexemplar bekomme oder das Buch selber kaufe.]

Continuous Testing?

Bei Continuous Testing geht es um die unmittelbare und automatische Rückmeldung ob die gerade getroffene Entscheidung die Software in die richtige Richtung bringt. Rady und Coffin nutzen das Speichern einer Datei als Taktgeber. Das Speichern (oder genauer die dadurch veränderte Datei) startet im Hintergrund und ohne weiteres Zutun des Entwicklers die automatisierten Tests. Als Entwickler braucht man nur noch die Konsole anzuschauen und sieht anhand der Farben sofort ob die Tests noch funktionieren.

Kontinuierliches Testen kann man wie von den Autoren gleich zu Beginn des Buches erwähnt recht einfach haben:

Open your favorite editor or IDE. Take whatever key you have bound to Save and rebind it to Save and Run All Tests. Congratulations, you’re now testing continuously.

Wer selber schon automatisierte Tests geschrieben hat weiss dass dies damit nicht wirklich gemacht ist: Tests brauchen eine gewisse Zeit um ein Ergebnis zu liefern, es gibt bald einmal Abhängigkeiten mit Umsystemen und wenn man noch GUI-Tests benötigt wird es erst recht aufwendig.

Dies ist auch den Autoren bekannt. Daher steht diese Textstelle auch am Anfang und nicht am Ende des Buches. Es ist nicht das Ziel von Continuous Testing immer alle Tests laufen zu lassen – das ist die Aufgabe von Continuous Integration nach dem commit. Es gibt viele Tests die in sehr kurzer Zeit einem eine grosse Gewissheit geben, dass alles läuft wie es soll. Die Tests gilt es zu finden und häufig auszuführen.

Um einem in die Lage zu bringen diese Tests zu identifizieren und mit einem passenden Ansatz zu testen ist das Buch in 3 Teile gegliedert.

Teil 1: Ruby und Autotest

Der erste Teil geht das Konzept Continuous Testing für Ruby an. Autotest wird dabei verwendet um die Dateien zu überwachen und die Tests auszuführen. Mit einfachen Erweiterungen kann man Autotest dazu bringen auch gleich noch die einzelnen Dateien nach TODOs abzusuchen.

Neben den Werkzeugen wird in diesem Teil auch grundlegendes zum Testen vermittelt (wie FIRE: Fast, Informative, Reliable and Exhaustive). Dies bleibt aber oberflächlich und ist vor allem da um das Wissen aufzufrischen (im Sinne von da war doch mal was).

Hilfreicher fand ich wie diese Theorie dann konkret angewendet werden kann. Als gelungenes Beispiel fand ich das Mocken von Twitter oder das Erkunden der API von MongoDB.

Teil 2: Rails, JavaScript und Watchr

Im 2. Teil geht es um komplexere Projekte. Bei Rails sind migrations (anpassen der Datenbank) ein Thema das man eingehend testen will. Aber auch JavaScript sollte bereits zur Entwicklungszeit getestet werden. Die so hinzukommenden Abhängigkeiten (Datenbank, Webbrowser, usw.) müssen mit anderen Werkzeugen getestet werden als die einfachen Ruby-Projekte aus dem 1. Teil.

Um die Dateien zu überwachen wird hierfür Watchr vorgestellt. Dieses Tool kann im Gegensatz zu Autotest nicht nur Tests ausführen, sondern jedes beliebige Kommando (wie Beispielsweise die Prüfung von CSS-Dateien mit Sass).

Da mit zunehmender Komplexität die Tests länger laufen muss auch in diesem Bereich etwas gemacht werden. Spork hilft hier indem die Testumgebung nicht bei jedem Testdurchlauf neu initialisiert werden muss.

Das Testen von JavaScript wird auf mehreren Ebenen angegangen. Einfache Dinge die keinen DOM benötigen werden mit Node.js getestet, für die komplexeren Szenarien kommt jsdom zum Einsatz. Für mich hätte man die JavaScript-Tests gerne eingehender behandeln können. So blieben bei mir doch mehr Fragen offen als ich Antworten erhalten habe. Dafür hätte man das Kapitel über funktionales JavaScript im Appendix (Teil 3 des Buches) gerne weglassen können.

Ruby-Kenntnisse nötig

Im Gegensatz zu den Autoren bin ich der Meinung dass man die Grundlagen von Ruby kennen muss um dem Buch folgen zu können. Man muss sicher kein Experte sein. Wenn man aber zu einem neuen Konzept auch noch gleich eine neue Sprache lernen soll wird die Lernkurve sehr steil.

Continuous Testing ist ein sprachunabhängiges Konzept und lässt sich somit auch ausserhalb von Ruby und JavaScript nutzten. Um die Arbeitsumgebung aufzuzeigen werden aber sehr viele Werkzeuge eingeführt die spezifisch für Ruby und Rails sind. Ob sich dies wirklich jemand durchlesen will der sich nicht für Ruby interessiert? Ich würde sagen Nein. Lässt man diese Teile aber weg bleibt vom Buch nicht mehr viel übrig.

Fazit

Continuous Testing ist ein interessantes Konzept. Die automatische Testausführung scheint zwar nur ein kleiner Schritt zu sein. Ein klein wenig Code zu schreiben und gleich sehen zu können ob die Tests damit erfüllt sind hat etwas sehr motivierendes. Es bedingt aber das man seine Software testgetrieben entwickeln will.

Will man so Software in Ruby/Rails entwickeln ist dieses Buch ein guter Einstieg. Macht man schon TDD und will von Ruby nichts wissen schaut man sich besser nach einem anderen Buch um.

Zum Buch

"Continuous Testing – with Ruby, Rails, and JavaScript" von Ben Rady und Rod Coffin, 2011 The Pragmatic Programmers, ISBN 978-1-93435-670-8, 160 Seiten, Englisch