Fortgeschrittene Techniken der testgetriebenen Entwicklung

Veröffentlicht am 30.05.2007, letzte Änderung am 09.07.2007

Im letzten Monat fand die diesjährige JAX statt. Johannes Link und ich hatten einen Power Workshop zu fortgeschrittenen Techniken der testgetriebenen Entwicklung.

Umbesetzung am frühen Morgen

Leider musste mir Johannes erkältungsbedingt am Morgen des Workshops absagen. Prinzipiell kein Problem, einer der Gründe dafür, einen Workshop zu zweit einzureichen, ist schließlich Ausfallsicherheit. Nur wurden uns wenige Tage vor dem Workshop voraussichtliche 70 Teilnehmer angekündigt, und bei dem hohen Anteil von praktischen Übungen wäre das für mich alleine doch recht hektisch geworden.

Glücklicherweise traf ich beim Frühstück Stefan Roock, einen meiner Freunde von it-agile aus Hamburg. Er meldete sich freiwillig, mir bei den Übungen auszuhelfen.

Warum testgetriebene Entwicklung?

Meine Lieblingsfrage bei Testworkshops ist immer, warum wir eigentlich testgetrieben entwickeln sollen. Tests sieht jeder ein, automatisierte Tests auch, warum aber testgetrieben?

Meine Antwort darauf: Die Relevanz von Testergebnissen hängt unter anderem von zwei Dingen ab — sie müssen möglichst aktuell sein, und möglichst viele Teile des Codes erreichen. Sind die Testergebnisse alt, machen sie nur noch eine Aussage über das System zum Zeitpunkt der Testausführung, und dieses System kann stark vom aktuellen System abweichen. Decken die Tests nur einen geringen Teil des Systems ab, haben die Ergebnisse nur wenig Aussagekraft über das Gesamtsystem.

Entwickeln wir testgetrieben, dann führen wir die Tests sehr häufig aus, damit haben wir immer aktuelle Ergebnisse. Und das testgetriebene Vorgehen führt zu einer hohen Testabdeckung: Halten wir sie komplett durch, werden 100% des Systems durch die Tests erreicht.

Eine Folgefrage ist oft, ob testgetriebene Entwicklung nicht zu teuer ist. Schließlich kostet die Testerstellung Zeit. Als Antwort darauf wird oft argumentiert, die Investition mache sich später durch höhere Qualität bezahlt. Das denke ich auch, aber empirische Untersuchungen dazu sind rar. Andererseits sollten wir lieber erst einmal in Tests investieren und sehen, wann wir zu dem Punkt kommen, an dem wir denken: Unsere Qualität ist zu hoch, wir sollten weniger Tests schreiben.

Groovy

Um den Aufwand für die Erstellung der Tests in Java zu verringern, kann man die Tests in Groovy, einer dynamisch typisierten Skriptsprache für die Java Virtual Machine, implementieren.

Natürlich können wir auch Systemteile oder das gesamte System in Groovy statt Java schreiben. Oftmals wird der Code dadurch kürzer und besser verständlich. Ein Beispiel: Nehmen wir an, wir haben in der Variablen users eine Liste von Objekten der Klasse User. Bei User-Objekten gibt der Getter getFirstName() den Vornamen zurück. Wir wollen nun alle Vornamen alphabetisch sortiert durch Kommata getrennt der Variablen firstNamesForDisplay zuweisen.

In Java kann das zum Beispiel so aussehen: 

List<String> firstNames = new ArrayList<String>();
for (User user : users) {
    firstNames.add(user.getFirstName());
}  
Collections.sort(firstNames);
StringBuffer result = new StringBuffer();
for (Iterator<String> it = firstNames.iterator(); it.hasNext();) {
  result.append(it.next());
  if (it.hasNext()) result.append(", ");
}
String firstNamesForDisplay = result.toString();

Sicherlich kann man den Code noch ein wenig reduzieren, aber der Groovy-Code wird immer schöner bleiben: 

String firstNamesForDisplay = users.firstName.sort().join(', ')

Im Workshop kam die Frage auf, Groovy der Nachfolger von Java sein wird. Natürlich ist jede Antwort auf so eine Frage ein Blick in die Kristallkugel. Meiner Meinung nach hat Groovy das Potenzial, einen großen Teil der Java-Entwicklung zu ersetzen, da man mit viel weniger Code viel mehr erreichen kann.

Leider hat eine dynamisch getypte Sprache Nachteile, wenn es um die Werkzeugunterstützung geht. Eine gute Code Completion zu implementieren, ist schwierig, da die Typen von Variablen zur Übersetzungszeit nicht bekannt sind. Auch automatisierte Refactorings sind durch die dynamischen Eigenschaften der Sprache schwieriger zu implementieren, und bleiben wohl am Ende immer unzuverlässiger als für Java.

Infos zum Workshop

Johannes hat unsere Folien zum Workshop auf SlideShare veröffentlicht. Stefan ließ es sich nicht nehmen, über die Inhalte des Workshops zu bloggen (Teil 1, Teil 2, Teil 3). Auch einer der Teilnehmer fasste den Workshop in einem Blog-Eintrag zusammen.