Michaels Blog

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.

Test Driven Development (TDD) lebt davon, dass vor jeder Funktion ein Test zu schreiben ist, der die Funktion auf Korrektheit prüft. Von diesem Schema gibt es keine Abweichung. Und genau da entsteht ein Problem, dass immer dann entsteht, wenn man glaubt, komplexe Probleme auf genau eine Art lösen zu können. Dabei ist der Ansatz interessant. Aber mit der Dosis, mit der diese Medizin verabreicht wird, wird es zu Gift. Dafür gibt mehrere Gründe, ein paar möchte ich beleuchten.

Nur Hellseher wissen, was später herauskommt und nicht mal die liegen richtig**.**

In dem ich einen Test für die Lösung eines Problems schreibe, lege ich das Endergebnis schon fest. Doch in vielen Fällen trifft diese erste Lösung nicht ins schwarze, sondern nur mit viel Glück überhaupt die Scheibe. Je länger man sich mit dem Problem beschäftigt, desto vielschichtiger werden die Lösungsansätze. Die Schwierigkeit mit einem Test ist dann, das es mit einem vorhandenen Stück Code schwerer fällt, sich von dieser Fehlentwicklung zu lösen.

Mir hat jemand die Zeit gestolen.

Wenn man TDD konsequent Anwendet, dann geht nichts mehr ohne Test. Das führt dazu, dass entweder die zu testenden Funktionen komplexer werden, weil man sich ja doch irgendwie scheut, für alles und jeden Tests zu schreiben. Oder es führt dazu, dass man fein granulierte Funktionen entwickelt, die jede mit einem Test geprüft werden. Man hat also für ein Problem doppelt soviel Code wie nötig geschrieben hat. Wenn man dann das Problem am Anfang auch noch (wie zu erwarten war) falsch eingeschätzt hat, dann sieht die Quote wohl noch schlechter aus, weil dann viel Testcode und Funktionscode durchs Refactoring geschoben wurde.

Die Lösung

Es kommt wie immer auf die Dosis an. Aber es erscheint mir aus den oben genannten Gründen zu riskant, als das man mit einem Test anfangen sollte. Bei einem Problem erstelle ich meist einen minimalen Funktionsprototypen, an dem man dann mit einem geeigneten Test a) die Funktion und vor allem b) die Handhabbarkeit testen kann. Dabei teste ich nur Dinge, bei denen ich davon ausgehe, dass da etwas schief laufen kann. Wenn man entsprechend selbstkritisch ist, entsteht eine gute Mischung aus Test- und Funktionscode, bei dem man dann den Testcode getrost der Problemlösung zurechnen kann, denn er demonstriert die Anwendung der Lösung an einem Beispielproblem. Getreu dem Motto: „Code ist Dokumentation“ hat man eine Dokumentation geschaffen, die nicht so schnell veraltet, die notwendige Information in einer für den Entwickler verständlichen Form transportiert und dabei auch noch schön kompakt ist.

Da ich Abkürzungen nicht mag (steht ein Teil des Problems drin), aber der eine oder andere doch einen Begriff haben möchte, mit dem er dieses Vorgehen benennen kann, nenne ich das ganze: Development is Code, Test and Documentation (DICTAD/DCTD).