Rumms, die Glastür kracht ins Schloss. Schwere Schritte nähern sich unaufhaltsam vom Ende des Gangs. Ein Bein schleift nach. Käptn Ahab auf hoher See. Dann verdunkelt sich mein Büro. Ein Schatten schiebt sich über meinen Schreibtisch wie eine Sonnenfinsternis.
„Na, wie schauts?“,
dröhnt er. Der Mann meiner schlaflosen Nächte steht im Türrahmen. „Frage oder Urteil?“, schießt es mir noch durch den Kopf, immer ganz der Philosoph. Immer Haltung bewahren. Ich muss etwas antworten. Zum Stand des Projektes, dass ich vor genau 91 Tagen übernommen hatte.
Nein, ich hätte es nicht annehmen sollen, dieses Projekt. Doch vielleicht das Projekt, aber nicht diesen Code. Angeblich nur ein paar Änderungen, mal eben nebenher, nichts Wildes! Doch ruckzuck gehen die Wochen ins Land. Man probierte hier und setzte dort an. Sobald ich irgendwo was änderte, krachte es wo anders im Klassenmeer. Mein Vertrauen in den Code schwand dahin, der Liefertermin rückte näher. Irgendwie musste ich raus aus dieser Miesere!
Rettung? „Test-Driven-Development“. Morgens um fünf, hatte ich eines Nachts die Seite der CleanCodeDeveloper entdeckt!
Dort war im 3. Grad die Rede von automatisierten Unit Tests und Testattrappen (Mockups). Schnell den Kenntnisstand über TDD vertieft, NUnit runtergeladen und das Tutorial durchgecheckt. Ich beschloss, das Verfahren auf das aktuelle Projekt anzuwenden.
Doch nach Anfangserfolgen Ernüchterung! Wo sollte ich mit dem Testen anfangen und wie sollte ich erkennen, wann ich genug getestet hatte? Nach wenigen (Test)durchläufen hatte ich den Überblick verloren. Dafür gesellte sich nun das ungemütliche Gefühl von Wiederholungen der vertrauten alten Fehler, nur im neuen Gewand, mit anderer Technik, zu mir an diesen einsamen Abenden in meiner Programmierstube, während der Rest der Welt Fußball schaute. Coole Ratschläge aus der Blogosphäre zur Benennung der Tests „die-Klasse-Sollte-X-tun-Und-das-Ergebnis-Y-erzielen“, waren auch nicht gerade inspirierend. Die entscheidende Frage blieb unbeantwortet: „Wann habe ich genug getestet?“ Resignation zog wie klammer, feuchter Bodennebel in meine Stube. Den Job an den Nagel hängen? Müllmann werden? Oder Traumtänzer, Zahlenjongleur im Zirkus? Eine Therapie anfangen? Oder in die Wüste gehen? Nach meinem bescheidenen Wissenstand gabs dort immerhin keine Bodennebel.
Während ich so über die Zukunft sinnierte, wollte mein Schicksal, dass mir in einem schlaflosen Wachttraum Behaviour-Driven-Development erschien. Erneut Funken der Hoffnung! Ich begann Szenarien zur Nutzung der Anwendung zu bauen, immer das Ziel des Anwenders vor Augen. Ich begann ganz von vorne: das Starten der Anwendung und die Eingabe der ersten Daten im Gherkin-Stil zu dokumentieren.
Auf einmal wurde mir klar, dass ich so dem Weg des Anwenders durch das Programm folgte. Die Szenarien des BDD wurden auf einmal Brücken zu den User Stories der Anforderungsanalyse. Ich befand mich zwar nun auf der Ebene der Integrations- und Oberflächentests, hatte aber ein Ziel vor Augen. Endlich konnte ich die gesamte Anwendung zielorientiert auseinander nehmen und refaktorisieren. Genau so musste ich die Tests anpacken! Das wusste ich nun. Blieb nur die Frage, wann konnte ich aufhören. Und diese konnte ich mit Code Coverage beantworten. Denn sobald ich alle praxisrelevanten Wege durch das Programm in Form von Szenarien spezifiziert hatte und dann den Nachweis hatte, dass alle Code-Zeilen durchlaufen waren, war ich fertig. Wow!
Rumms, die Glastür kracht ins Schloss. Schwere Schritte. Gelassenheit in mir. Ich bin ganz Blumenkind. Depression, Bodennebel ade! Auch Chefs sind Menschen, sinniere ich in der mir eigenen Großzügigkeit. Ich strahle innerlich wie alle Atommeiler dieser Erde zusammen. Die Schritte nähern sich. Mein ganzes Lächeln für dieses Sonnensystem! Dann der Schatten. Er schiebt sich über meinen Schreibttisch.
„Na, wie schauts?“.
Fortsetzung folgt. Dann geht’s um das SUB-DD-Vorgehensmodell. Mein erster Artikel hierzu wird sich mit dem Anforderungs-Management befassen.
