Testgetriebene Entwicklung

Grundgedanke

Der "klassische" Entwickler bekommt eine Problembeschreibung, implementiert dann eine Lösung, schaut daß sie funktioniert und ist fertig...

Der Knackpunkt dabei ist die Frage, wie das Funktionieren überprüft werden soll. Wir gehen mal davon aus, daß das Problem so beschrieben ist, daß der Entwickler genau versteht wie das Ergebnis auszusehen hat. Dann kann er mit diesem Wissen sein Programm überprüfen. Was aber, wenn das Programm geändert oder ergänzt werden soll? Dann muß der Entwickler erneut überprüfe ob noch alles tut und im Laufe der Zeit wächst der Test-Aufwand immer weiter an.

Die Lösung besteht darin, die Überprüfung zu automatisieren. Dann kann eine billige Maschine die Überprüfung durchführen, während der teure Entwickler wichtige Dinge tut.

Der Test wird damit zu einem integralen Bestandteil der Software, wird mit dem produktiven Code zusammen erstellt und gepflegt.

Test First Development

Wie der Name schon andeutet, wird die Erstellung des Unit-Tests der Erstellung des Produktiv-Codes vorangestellt. Das hat schon den unmittelbaren Vorteil, daß nicht implementiert wird, wenn nicht klar ist was getan werden soll.

Dieses Vorgehen hat damit zwei Schritte:

1. Schreibe einen Test der die Funktionalität testet und fehlschlägt (Test ist "rot")
2. Implementiere die Funktionalität bis der Test durchläuft (Test ist "grün")

Die Herausforderung besteht -- zumindest am Anfang -- darin, Probleme so in einzelne Funktionalitäten zu schneiden, daß sie sich in einfachen Unit-Tests testen lassen. Das Schreiben der Tests ist eine Fähigkeit die man sich durch Üben recht schnell aneignen kann.

Dieses Vorgehens hat folgende Vorteile:

• Die Test-Erstellung wird nicht vergessen
• Am Ende der Implementierung ist der Code mit Tests vollständig abgedeckt und dokumentiert
• Der Code kann bei Erweiterung mit Unit-Tests abgesichert werden
• Es ist klar dokumentiert, was der produktive Code tun soll

Test Driven Development (TDD)

Gerät durch das sture Hinzufügen einzelner Features der Blick auf das Gesamtprogramm aus dem Fokus, wird das Endergebnis als ein Haufen zusammengeworfener Methoden und Klassen dastehen. Zwar garantieren die Tests, daß das Programm tut was es soll, aber der arme Mensch der das später erweitern soll wird keine Freude daran haben.

Durch Hinzufügen eines weiteren Schritts kann man das Verfahren zum TDD ausweiten wie Kent Beck es im Rahmen des "extreme Programming" beschrieben hat (citation?).

Halte nach jedem Schritt (bzw. nach jedem grün gewordenen Test) inne und sieh Dir das Gesamtprodukt an. Überlege Dir:

• Kann ich etwas besser machen?
• Kann ich etwas zusammenfassen?
• Kann ich etwas verallgemeinern?

Setze Maßnahmen, die Dir sinnvoll scheinen um und überprüfe das Ergebnis anhand der Unit-Tests.

Wichtig dabei ist:

Die Änderungen dürfen keine Änderungen an der bestehende Funktionalität mit sich bringen

Dieses Vorgehen –- man nennt es Refactoring –- erfordert Übung und Erfahrung. Zögere nicht, Kollegen hinzuzuziehen, wenn Du damit Schwierigkeiten hast oder Anregungen brauchst.