Test Driven Development (Teil 3 von 3)

Nach den Grundlagen und einem wilden Beispiel findet der TDD-Dreiteiler hier seinen Abschluss. Um reinzukommen, hier nochmal der aktuelle, fertige Stand in Gänze:

genug ist genug ist genug

Einen weiteren Testfall zu schreiben, lohnt zu diesem Zeitpunkt nicht mehr: Von Integer-Overflows mal abgesehen kriegen wir den Code nicht mehr kaputt. Einen Test hinzuschreiben, der von Anfang an grün ist, bringt nichts (wir erinnern uns: ein neuer Test soll initial immer rot sein). Nach der reinen Lehre wird ein neuer, sofort grüner Test auch sofort wieder gelöscht.

(Mit dieser Regel habe ich in der täglichen Arbeit manchmal noch Probleme. Es gibt manchmal ein, zwei wichtige Konstellationen, die ich ganz sicher abprüfen möchte, auch wenn meine Implementierung zufällig auf Anhieb so korrekt war, dass ich während der Entwicklung keinen passenden fehlschlagenden Test konstruieren konnte. Letztendlich ist bei dem strengen Vorgehen das Erlaubt-Sein eines einzelnen Testfalles davon abhängig, wie die Zwischenschritte auf dem Weg zum fertigen Code waren. Programmiert man linksrum, ist man an dem Testfall vorbeibekommen, programmiert man rechtsrum, kann der Fall nie rot gewesen sein – obwohl beide Male der gleiche Code entstanden ist. Das klingt mir schon sehr übertrieben-verkopft. Also schreibe ich durchaus mal eine „unerlaubte“ zusätzliche Testkonstellation. Dann kann ich nämlich ruhig schlafen und muss keine Angst haben, dass jemand später was ändert, was dann genau den wichtigen Fall kaputtmacht. Das geht aber auch schon ein wenig in Richtung Akzeptanztest. Bezogen auf das obige Codebeispiel: Da ich ja argumentiert hatte „Null = neutrales Additionselement = Sonderfall“, wäre ein Testfall mit 0 vielleicht ein solcher Absicherungstest, den ich noch ergänzen würde.)

Mein Fazit

Ich kenne TDD jetzt seit ca. einem halben Jahr. Am Anfang war das sehr ungewohnt und komisch. So habe ich die 25 Jahre vorher nicht programmiert. Es gefällt mir aber immer mehr und es lässt sich tatsächlich mit etwas Disziplin und Lust zum Ausprobieren auch in der täglichen Arbeit in echtem Code benutzen.

Die Zeit, die fürs Schreiben der Testfälle draufgeht, hat man wieder drin, wenn man den ersten Bug nicht suchen muss, weil man ihn schon beim Testen abgefangen hat. Oder wenn man zwei Stunden lang ungestört per TDD und Unit-Tests programmiert und dann zum Abschluss einmalig die Anwendung hochfährt und manuell testet anstatt wie früher alle drei Minuten das lokale Testsystem durchzustarten und sich erneut auf die Maske durchzuklicken, an der man gerade schraubt…

Ach ja: das geht nicht nur in Java, sondern mit jeder Sprache, in der man irgendwie Unit-Tests hinbekommt. Zur Not auch in Bash oder COBOL, wobei bei letzterem der Compile-Zyklus und die Jobausführung den TDD-Zyklus ziemlich schmerzhaft ausbremsen (zumindest wenn man „richtiges“ COBOL auf einem Großrechner macht, denn merke: COBOL ohne BUSINESS ist zwar COOL, aber nicht cool).

Try it!

IDE aufgemacht, neues Projekt angelegt, Test-Framework initialisiert und losgehackt: Beim Selbst-Ausprobieren kommt man am ehesten auf den Geschmack. Genau für so etwas sind Katas gedacht: Man könnte sich z.B. mal testgetrieben an der Simple Poker Hands Kata versuchen und beim ersten Mal ruhig etwas übertrieben kleinschrittig vorgehen so wie hier im Beispiel.

Oder man sucht sich eine Veranstaltung am Global Day of Coderetreat (Samstag, 22.10.2016; hierzulande häufig über die Softwerkskammer) irgendwo in seiner Nähe – da kann man das mal einen ganzen Tag lang live an einer interessanteren Aufgabe durchexerzieren, jeweils als Pair Programming mit wechselnden Teams und steigendem Schwierigkeitsgrad (Stichwort: Constraints, z.B. sind in einer Runde nur void-Methoden erlaubt). Geile Scheiße – mitmachen!