Testgetriebene Softwareentwicklung ist eigentlich eine tolle Sache, die jeder mal probiert haben sollte. Nicht etwa, weil es die beste Methode wäre, Software zu entwickeln. Es ist viel mehr so, dass häufig viel zu wenig Tests geschrieben werden und nicht selten auch die Einsicht fehlt, warum Tests geschrieben werden sollen. Manchmal ist es auch nur die Faulheit, die davon abhält, ein paar mehr Tests zu schreiben. Einmal testgetrieben zu entwickeln, verschafft die Erfahrung, dass die Qualität der Software signifikant steigt, wenn gute Tests erstellt wurden. Die Erfahrung, was gute Tests sind und worauf es ankommt, bekommt man gleich mit oben drauf.
Sehr gut funktioniert das übrigens in der Java-Welt, wenn man auch gleich bei der Entwicklung darauf abzielt, entkoppelten Code zu schreiben. Spring ist da ziemlich hilfreich.
Zurück zur testgetriebenen Entwicklung. Ein großes Haken ist natürlich, dass testgetriebene Entwicklung zu Beginn des Projektes mehr Zeit benötigt. Außerdem ist es unter Entwicklern meist unbeliebt, Testcode zu schreiben. Dem lässt sich allerdings entgegen wirken, wenn man Teams zu zwei Personen bildet, bei der gemeinsam die Spezifikation ausgearbeitet wird und abwechselnd der eine die Implementierung und der andere die Tests schreibt. Nach einiger Zeit erhält man dann ein Projekt, das eine gute Testabdeckung bietet und wenig fehleranfällig auf Änderungen reagiert.
Tests gleich zu schreiben ist auch deshalb gut, weil ein Test, der nicht unmittelbar nach oder eben vor der Implementierung geschrieben wurde, oft nie geschrieben wird. Zumindest so lange nicht, bis genau dort ein Fehler auftritt.
via krsteski.de
Keine Kommentare:
Kommentar veröffentlichen
Hinweis: Nur ein Mitglied dieses Blogs kann Kommentare posten.