by:

Nachdem ich jetzt 2 Coding Dojos zum Thema Test Driven Development besucht habe, dachte ich, es ist mal an der Zeit auch meinen Senf dazu zu geben.

Was ich positives aus TDD für mich extrahiert habe:
TDD ist der Versuch die Programmierer dazu zu bewegen vor der Implementierung sehr konkret über die Spezifikationen sowie nötigen Schritte nachzudenken.
Gut das klingt mal super, allerdings auf den ersten Blick wirkt das ganze dann schon sehr eigenartig:

Wie funktioniert Test Driven Development ?

Eine Iteration in TDD sollte folgendermaßen ausschauen (aus wikipedia)

1.) Schreibe Tests für das erwünschte fehlerfreie Verhalten, für schon bekannte Fehlschläge oder für das nächste Teilstück an Funktionalität, das neu implementiert werden soll. Diese Tests werden vom bestehenden Programmcode erst einmal nicht erfüllt bzw. es gibt diesen noch gar nicht.

 

2.) Ändere/schreibe den Programmcode mit möglichst wenig Aufwand, bis nach dem anschließend angestoßenen Testdurchlauf alle Tests bestanden werden.

 

3.) Räume dann im Code auf (Refactoring): Entferne Wiederholungen (Code-Duplizierung), abstrahiere wo nötig, richte ihn nach den verbindlichen Code-Konventionen aus etc. Natürlich wieder mit abschließendem Testen. Ziel des Aufräumens ist es, den Code schlicht und verständlich zu machen.

Moment. What ???

Man schreibt also erst den Test, für eine Methode die noch gar nicht existiert und programmiert sie dann mit möglichst wenig Aufwand ... 

Ich hab mir persönlich schon schwer genug getan von der prozedualen Programmierung (top down Ansatz) zur objektorientierten Programmierung und jetzt soll ich auch noch Tests schreiben für Methoden die noch nicht existieren ?

Was spricht für Test Driven Development ?

Man wird "gezwungen" sich schon vorher sehr genaue Gedanken über seine Implementierung zu machen!

Das Ziel, am Ende SourceCode zu haben, der möglichst schlank programmiert und getestet ist, halte ich doch für etwas hochgegriffen, werde das aber gerne bei eigenen Projekten ausprobieren um mich vom Gegenteil überzeugen lassen.

Was spricht gegen Test Driven Development ?

Es ist ein Mehraufwand, ein Mehraufwand der sich erst nach einer gewissen Anzahl von Testdurchläufen rentieren kann.
Wie oft das ist und wann der Return Point of Investment ist, dass überlasse ich dann doch lieber Leuten die auf eine andere Art geistige Wunder vollbringen.

Im wesentlichen bedeutet dies für viele Programmierer ein komplettes Umdenken, was schwierig wird wenn man an die Adaption denkt, schließlich macht TDD auch nur dann Sinn, wenn jeder der Beteiligten an einem Projekt mitmacht.

Test ist vieleicht in dem Zusammenhang auch der falsche Ausdruck, es ist mehr eine Mischung aus Vorlage und Test.

Wer immernoch glaubt das TDD ein unglaublicher Blödsinn ist, der sollte sich mal die Videos von makandra anschauen
http://www.makandra.de/malennachzahlen/kurs/
Ansonsten Wikipedia ist natürlich auch immer eine Quelle
http://de.wikipedia.org/wiki/Testgetriebene_Entwicklung

Liebe Grüße

Andreas



Name:
Der Artikel schaut mir sehr nach jemandem aus der die begeisterung nach TDD noch nicht gefunden hat. Alle Entwickler die ich kenne, die Bisher in wirklich Testgetriebenen Projekten entwickelt haben waren mehr oder weniger begeistert.
Allerdings ist es am Anfang schon gewöhnungsbedürftig.
Wer noch keine Erfahrung mit TDD hat dem empfehle ich mal eine Code Kata im Coding Dojo zu machen das kann man häufig in Usergruppen oder ihr organisiert das unter kollegen.
Wenn ihr dafür nen coach benötigt :-) Ich aber auch andere bieten sowas an.

Als ich das erste mal davon Erfahren habe war ich auch eher skeptisch, das mit den kleinen schritten adaptiert man allerdings sehr leicht. Und wenn man erstmal testgetrieben arbeitet merkt man sehr schnell es macht aufgrund des schnellen Feedbacks unheimlich spass. "Rot-Grün-Rot-Grün."