Test Driven Development is Pre-Optimization

14.04.2009 09:58

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).


Empfehlungen: handy taschen | Good Job - Bad Job