TDD ist auch nur eine extreme Sichtweise
Es muss Gründe geben, warum nicht jeder Entwickler bei der Erwähnung von Test Driven Development (TDD) mit “ach klar, genau” antwortet. Ich möchte dazu mal etwas ausholen. Softwareentwicklung ist ein kreativer Prozess. In diesem Prozess gibt es einige hochbegabte Entwickler, sehr viele im guten Mittelfeld und einige, die jede Kreativität vermissen lassen. Wo der eine mit dem ersten Wurf bereits einen sehr guten Treffer landet, muss sich der andere langsam an das Ziel herantasten. Das ist ganz normal, so sollte es ja auch sein.
In dem man nun TDD propagiert, stellt man alle Entwickler gleich, in dem man sagt, schreibe zuerst den Test, denn was Du entwickelst funktioniert mit hoher Wahrscheinlichkeit nicht. Das ist spannend. Wenn man Unterschiede zwischen Entwicklern macht, und ich hoffe, da gibt es keine Zweifel, dass dem so ist, dann soll es eine Arbeitsmethode geben, die für alle gleich gut funktioniert? Mir fällt kein Beispiel aus anderen Bereichen ein, wo das der Fall ist.
Ich glaube, und das zeigt mir meine Erfahrung, dass für den erfahrenen Entwickler eher das Motto gelten sollte: Teste, wo Du es für wahrscheinlich hältst, dass Du ein Fehler gemacht hast. Und ich habe es bisher nicht als vorteilhaft erachtet (und darum geht es ja hauptsächlich), den Test vor der Funktion zu schreiben. Dann das würde darin enden, dass ich an zwei Stellen gleichzeitig Anpassungen vornehmen muss, bevor überhaupt eine Funktion umgesetzt wurde. Ich weiß nicht, wie es anderen Entwicklern so geht, aber ich passe den Code, der entsteht sehr oft an – wie ein Gemälde, dass sich mit jedem Pinselstrich vervollständigt, aber eben auch Bereiche wieder ausradiert und neu gezeichnet werden müssen. Es ist nicht nur eine Funktion, die so entsteht, sondern gleich ein kleines Lösungsgebilde. Würde ich jedes mal davor einen Test schreiben, würde ich auf diese Weise extrem viel für die Tonne produzieren.
Als Entwickler passt man seine Arbeitsweise so an, dass die eingesetzten Methoden einen persönlichen Vorteil offenbaren. Wenn dieser Vorteil eintritt, ist Überzeugungsarbeit nicht notwendig. Dass es immer wieder Diskussionen zu z.B. TDD gibt, liegt wohl daran, dass es nicht für jeden die beste Wahl ist.
Tags: entwicklung, software, tdd, test driven development
Am 24. Juli 2009 um 04:16 Uhr
Ich schreib Test auch nur im Nachhinein und auf “educated guess” hin.
Schrieb.
Seit ich Kent Becks JUnitMAX benutze, schreibe ich immer öfter den Test zuerst. JUnitMAX führt bei jedem Speichern im Hintergrund alle Tests aus, und markiert Fehler direkt im Testcode. Sprich, ist der Test einmal geschrieben muss ich nie mehr zum Testrunner zurückkehren. Das verleitet selbst Faulpelze wie mich zum Test-first.
Am 24. Juli 2009 um 10:22 Uhr
JUnitMAX scheint wohl ein interessantes Produkt gewesen zu sein.. ich betone die Vergangenheit, weil ich erst kürzlich las, dass die Entwicklung eingestellt wird. Auszug aus der Seite http://junitmax.com/junitmax/subscribe.html: JUnit Max is no longer being actively developed or sold. Das ist schade.
Spannend ist dabei, dass JUnitMAX bis zu dem Zeitpunkt, wo ich davon gehört habe, dass das Produkt eingestellt wird, überhaupt nichts davon gehört habe. Das finde ich schade, denn die Idee ist an sich sehr charmant.
Das bringt mich auf den Punkt, warum ich glaube, dass der JUnitMAX-Ansatz die Nachteile von purem TDD auffängt: extrem hohe Interaktivität. Der Grund, warum man als Entwickler ne IDE statt einem Texteditor benutzen sollte. Ich bin gespannt, ob es in dieser Richtung weitere Versuche geben wird, oder ob JUnitMAX vielleicht in einer anderen Form wieder auftaucht.