Warum haben (viele) Entwickler keine Lust auf das Schreiben von Unit-Tests?
Tobias Wasle und ich haben uns in der Mittagspause dazu Gedanken gemacht.
Meine These:
Ein Grund dafür ist, dass das Weglassen von Unit-Tests nicht zu direktem Feedback führt. Damit meine ich, dass der eigene Code vermutlich das tut, was er soll und wenn es (überhaupt) Probleme gibt, diese erst viel (evt. Jahre) später sichtbar werden.
Welche Möglichkeiten haben wir also, das Schreiben von Unit-Tests mit einem direkten Feedback zu verknüpfen?
Ein positiver Weg könnte sein, den Ansatz des TDD (Test Driven Development) zu wählen. Hier ist der erste Schritt, den Test zu schreiben, dann den eigentlichen Code schrittweise so zu entwickeln, dass der Test erst fehlschlägt (rot) und im Laufe der weiteren Entwicklung dann erfolgreich (grün) durchläuft. Ich bekomme also direktes (positives) Feedback, sobald mein Code korrekt ist.
Als Weg mit negativem Feedback („hey da fehlt ein Test“) könnte man sich dazu entscheiden, dafür zu sorgen, dass nur Code mit dazugehörigen (sinnvollen) Unit-Tests in das Projekt aufgenommen werden kann. Dies kann z.B. durch Peer-Review mit Freigab-Prozess passieren (Up-/Downvoting von Pull-Requests).
Im Gespräch mit KollegInnen im Team habe ich gelernt, dass beide Wege zu Akzeptanz aber auch Ablehnung führen.
Ein Teammitglied hat beim Thema Peer-Review die Angst vor dem Gefühl der Kontrolle angesprochen, ein anderes Mitglied war der Meinung, dass genau diese Kontrolle (Peer-Pressure) notwendig sei, um sich selbst zum Testen zu motivieren. Zitat: „Ich muss das Gefühl haben, dass ich Tests schreiben muss“
Die Anregung von Tobias war hier, nicht jeden zum Peer-Review zu verpflichten, sondern Freiwillige im Team zu suchen, die sich bereit erklären, den Peer-Review-Prozess für die eigenen Pull-Requests zu durchlaufen, um den anderen im Team ein Gefühl für die Methodik zu geben, ohne sich gleich selbst exponieren zu müssen.
Sehr spannender und ich glaube toller Ansatz.