Never in the field of software development was so much owed by so many to so few lines of code.

—Martin Fowler

Testgetriebene Entwicklung ist eines der prägenden Schlagwörter in der Softwareentwicklung nicht nur mit Java der letzen zehn Jahre. Das erste JUnit-Release 1997 und das Aufkommen von eXtremeProgramming (XP) führte ab dann zu fast revolutionsartigen Zuständen in der Software-Industrie. Testgetriebene Entwicklung als einer der Kern-Elemente von XP wurde zum absoluten Kult, von vielen als die Lösung aller Projekt- und Qualitätsprobleme herbeigesehnt, allerdings in wenigen Projekten vollständig realisiert. Vor XP war das Testen von Software aus Sicht des Entwicklers die Aufgabe von jemandem anderen, jetzt muss von jedem Entwickler alles getestet werden, was mit halbwegs vertretbaren Aufwand testbar ist – manchmal auch mit erheblich mehr Aufwand, als eigentlich vertretbar – und zwar automatisiert, wiederholbar und kontinuierlich.

Wie jede Revolution führte dieses Vorgehen zu Exzessen mit zum Teil zweifelhaften Ergebnissen. Es gab zwar glücklicherweise keine Guillotine, aber dafür existieren inzwischen genug Systeme mit aus verschiedenen Gründen unwartbaren oder degenerierten Tests, welche die Weiterentwicklung oder Migration eines Systems be- oder verhindern. Früher waren Legacy-Systeme Cobol-Systeme aus den 80-ern, heute gibt es viele unternehmenskritische Java-Systeme nicht nur aus den Anfängen des Jahrtausends, welche diese Bezeichnung genauso verdienen.

In diesem Vortrag soll ein systematischer Ansatz vorgestellt werden, mit dem bestehende automatisierte Tests und der entwicklungsbegleitende Testprozess in einem Projekt bewertet werden können – um Maßnahmen zur Sanierung bzw. Verbesserung ableiten zu können. In neu aufgesetzten Projekten können diese Kriterien zum Justieren des entwicklungsbegleitenden Testens verwendet werden.

Zusätzlich soll kurz auf eine Ideal-Architektur zur Testbarkeit und ein agiler Entwicklungsprozess eingegangen werden, um pragmatisch testgetriebene Entwicklung realisieren zu können.

Martin Schneider arbeitete annähernd zehn Jahre als Software-Entwickler, Berater und Coach in diversesten Kundenprojekten und Domänen, z.B. für Banken, Medienanstalten, Handelsunternehmen und in der Energiewirtschaft und verantwortet sein Februar 2010 das Qualitätsmanagement im Projekt Kraftwerkseinsatzplanung in einem großen Energieversorger.