Softwareentwicklung im Team – Teil 8 – Unit Tests

Im Artikel über Nightly Builds hatte ich mich in der Einleitung bereits einmal über Unit-Tests ausgelassen:

Im hektischen Alltag werden eh meist zu wenige geschrieben und die die existieren werden von den Entwicklern auch eher nur sporadisch ausgeführt. Das hat unter anderem zur Folge, dass Unit-Test mit der Zeit veralten, weil sie beim refactorn gerne vergessen werden. Anstatt sie dann anzupassen, werden dann auf Grund mangelnder Zeit die fehlgeschlagenen Tests einfach gelöscht oder auskommentiert.

Das trifft ziemlich exakt die Situation, die wir bei uns vorfanden.

7. Problem / Beispiel
Unit-Test

Zwar werden vereinzelt Unit-Test geschrieben, da diese aber nicht regelmäßig (sprich automatisiert) ausgeführt werden, ist deren Nutzen stark begrenzt. Sobald ein Continious Integration Server aufgesetzt wurde, stellt das aber kein Problem mehr da.

Lösungsvorschlag
Ziel sollte es für zukünftige Projekte sein, qualitativ hochwertigen Code auszuliefern. Und da gehört ein frühes Testen mittels Unit-Test dazu.

Vorteile
– Qualitativ hochwertigerer Code
– Probleme beim Refactoring werden frühzeitig erkannt

Nachteile / Probleme
– eine Etablierung ist langwierig, insbesondere wenn die Testcases ein nicht triviales Setting (Datenbankverbindung oder ähnliches) benötigen

Aufwand
– kurzfristig gesehen relativ hoch, langfristig aber wird sich das sicherlich auszahlen

Rückblickend gesehen
Tja, was soll ich sagen? Mit diesem Punkt sind wir auf der ganzen Linie gescheitert. Eins der größten Probleme war, dass die Zeitpläne immer so straff angesetzt waren, dass dafür gar keine Zeit blieb. Wie straff die Zeitpläne waren, soll kurzes anekdotisches Gespräch am Ende eines Kick-off-Meetings verdeutlichen:

Projektleiter: “… und an Tag X gehen wir produktiv. Ich weiß, dass ist ein ziemlich sportlicher Zeitplan.”
Ich: “Ähm… wo ist denn da die Testphase?”
Projektleiter: “Es gibt keine. Dafür haben wir einfach keine Zeit.”

Das traurige daran ist: dieses Gespräch HAT tatsächlich SO(!) stattgefunden! Wir hatten nie Zeit. Nicht zum testen. Nicht für’s Refactoring. Und für Unit-Test schon gar nicht. (Ein Arbeitskollege sagt(e) immer: wenn wir dafür keine Zeit haben, haben wir keine Zeit, unseren Job zu machen. Und recht hat er!) Mehrere Versuche, den Verantwortlichen näherzubringen, wie wertvoll Unit-Tests seien, wurden abgecancelt mit: “Das machen wir mal, wenn wir Zeit haben.” Das die von uns gebauten Kartenhäuser bei der kleinsten Änderung komplett zusammenzubrechen drohten, führte zwangsläufig dazu, dass wir noch weniger Zeit für’s Testen hatten, weil wir damit beschäftigt waren, unser Kartenhaus vor dem Einstürzen zu bewahren. Ein Teufelskreis.
Eins der größten Probleme dabei war, dass die Mitarbeiter, die am besten darin waren, auf die Schnelle was zu fixen, auch die waren, die am wenigsten von Unit-Tests hielten. Und diese zur Not auskommentierten. (Weil ja keine Zeit vorhanden war…) Das Problem lag also nicht ausschließlich an den Projektverantwortlichen, sondern teilweise auch in den eigenen Reihen.

Zusammenfassung
Ja, Unit-Tests SIND mit viel Aufwand verbunden. Und nein, diese Arbeit zahlt sich in der Regel nicht SOFORT aus. Ich bin auch kein Freund von TDD und schreibe auch nicht für jedes Projekt Unit-Tests (zumindest nicht, wenn ein kleines Programm lediglich aus zwei Klassen besteht). ABER: Unit-Tests sind ein Rettungsfallschirm, der sich im laufe eines Projektes irgendwann DEFINITIV auszahlen wird. Und mit einem CI-Server kann man sich auch sicher sein, dass die Tests ausgeführt werden.
Es braucht Zeit, bis man gute Unit-Tests schreiben kann. Und häufig wird man auch Design-Schwächen in seinem Projekt aufdecken, die vorher gar nicht aufgefallen sind, bis man versucht, entsprechenden Code zu testen.

Ausblick
Man mag es kaum glauben, aber Software wird auch manchmal fertig gestellt. Das mit der letzten Zeile Code aber das Projekt noch nicht zu Ende sein sollte, zeigt der nächste Artikel über Retrospektiven.

2 Gedanken zu „Softwareentwicklung im Team – Teil 8 – Unit Tests“

Hinterlasse eine Antwort

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *

Du kannst folgende HTML-Tags benutzen: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>