Wenn ein Entwickler eine Idee für ein neues Feature hat, oder findet, dass man den alten Code umstrukturieren sollte treten immer wieder die gleichen Probleme auf. Kann ich den alten Code ohne Risiko anpassen, so dass die alten Programmteile nachher noch laufen? Wenn ich das Programm von Hand teste, habe ich wirklich an alles gedacht?
Read more...
Lesetipps
Software - Hauptsache es läuft...
Test Driven Development - Erste Praxiserfahrungen
Wenn ein Entwickler eine Idee für ein neues Feature hat, oder findet, dass man den alten Code umstrukturieren sollte treten immer wieder die gleichen Probleme auf. Kann ich den alten Code ohne Risiko anpassen, so dass die alten Programmteile nachher noch laufen? Wenn ich das Programm von Hand teste, habe ich wirklich an alles gedacht?
Hier setzt Test Driven Development (TDD) ein - also testgetriebene Entwicklung. TDD bedeutet, dass man für jedes Stück Code, dass man programmiert zuerst ein Test schreibt, somit ist man sicher, dass ein Programmteil auch getestet ist und funktioniert. Wenn man irgendwann die Funktion anpassen will, kann man nach der Veränderung einfach den Test laufen lassen und sich sicher sein, dass die Funktionalität immer noch die gleiche ist.
TDD folgt dem einfachen Grundsatz:
Test schreiben
Test durchlaufen - Test schlägt fehl
Code anpassen
Test durchlaufen - Test funktioniert
Code Refactoring
TDD ein bisschen mehr beschrieben:
Test schreiben für eine kleine Funktionalität
Test durchlaufen lassen und sehen, wie der Test fehlschlägt
Den Test so einfach wie möglich, durch hinzufügen einer Funktionalität im Code, zum laufen bringen (hierbei können auch Codesünden begangen werden, dass spielt in der 1. Phase keine Rolle)
Test durchlaufen lassen und sehen, wie der Test funktioniert
Code Refactoring - Code so korrigieren, dass er sauber ist / Code Redundanzen entfernen
(jedesmal wenn eine Änderung am Code gemacht wird, muss wieder bei 1 begonnen werden bis das Refactoring abgeschlossen ist)
Zu beginn dachte ich auch, dass dies ja viel Zusatzaufwand bedeutet. Aber man muss bedenken, dass die Funktionen ja sowieso getestet werden müssen, warum also nicht schon vorher definieren, was man testen will? Ausserdem hat man diese Tests auch in Zukunft und Veränderungen können sofort gecheckt werden, ohne dass man von Hand durchgehen und überlegen muss, ob dies auch wirklich funktionieren könnte.
Ich habe noch einen interessanten Link im Netz gefunden, der Anhand eines Videotutorials von FizzBuzz zeigt, wie Test Driven Development mit Java/Junit funktioniert.
Quellen
Buch Test-Driven Development by Kent Beck
Begriff Test Driven Development by Wiki
