Und jetzt alles umgekehrt, bitte!
Bis jetzt wurde in allen Beispielen davon ausgegangen, dass zuerst der eigentliche Programmcode entwickelt wird, um daraufhin mit Unit Testing die einwandfreie Funktionalität abzusichern. Test Driven Development verfolgt einen umgekehrten Ansatz: Zuerst werden anhand von Spezifikationen die Tests für jedes zu entwickelnde Modul geschrieben. Anfangs werden erwartungsgemäß alle diese Tests fehlschlagen, da der Code noch gar nicht existiert.
Nach und nach wird dann der eigentliche Programmcode entwickelt und die Tests werden fehlerfrei durchlaufen. Ziel ist es, am Schluss alle Tests zu bestehen – denn dann funktioniert der Programmcode genau so, wie er laut den Spezifikationen soll. Ein großer Vorteil dieser Vorgehensweise ist die detailliertere Auseinandersetzung mit dem strukturellen Aufbau einer Applikation vor dem effektiven Entwicklungsprozess.
Wer häufig testet
Martin Fowler beschreibt auf seiner Website [2] die Vorgehensweise der Continuous Integration. Diese basiert auf dem Konzept, dass möglichst der gesamte Sourcecode durch Unit Tests abgedeckt sein sollte. Entwickler werden dazu angehalten, vor jeder Änderung alle Tests durchlaufen zu lassen. Zudem wird nach dem Einchecken einer Änderungen im Repository erneut ein kompletter Durchlauf aller Unit Tests gestartet. Durch das häufige Einchecken selbst kleinster Änderungen ist die Fehlersuche und Fehlerbehebung mit viel weniger Aufwand verbunden.
Fazit
Zusammenfassend kann man sagen, dass die Einführung von Unit Testing in einem Softwareprojekt einen nicht zu vernachlässigenden Aufwand bedeutet. Die kurzfristige Investition schlägt sich aber merklich in besseren Prozessen und saubererem Quellcode nieder und zahlt sich mittel- bis langfristig auf jeden Fall aus. Aus der Sicht eines Entwicklers ist der Einsatz von Unit Testing jedem Entwicklungsteam wärmstens zu empfehlen.




