Hätt ich das mal eher benutzt – Unit Tests

Erste Tests

Irgendwann Ende 2005 bzw. Anfang 2006 arbeitete ich an einem meiner ersten Projekte in C#. Es diente als Seminararbeit für mein Studium. Mein Ansporn war also besonders hoch und so nutzte ich auch automatisierte unit tests. Zu der Zeit waren jene Tests für mich Neuland, ich fand sie nicht schlecht, hatte ihr Potenzial aber leider noch nicht erkannt. In meiner damaligen, direkten Umgebung nutzte sonst nur einer Tests. (Zufällig war das Philipp 😉
Nach wenigen Wochen gab es dann aber ein Problem mit den Tests. Die Testprojekte konnten nicht mehr in Visual Studio geladen werden. Gleichzeitig war der Projektdruck aber hoch. Ich musste mich also entscheiden und nahm die Testprojekte aus den Solutions raus um die Projekte stemmen zu können. Das erneute Einführen vertagte ich.
Es kam dann natürlich anders und die Tests blieben für einige Jahre unangetastet. Eines Tages hatten die Setupprojekte ein ähnliches Problem. Ich fand heraus, dass es sich um eine ungünstige Funktionalität in Visual Studio handelte. Projektdateien bzw. die Templates wurden in Unterordnern angelegt. 1033 und 1031 waren die benannt, je nachdem um welche Lokalisation es sich handelte. Aus irgend einem Grund, wurde ein update für VS installiert, welches nicht zur Originalinstallation passte. Die Dateien lagen dann genau im falschen Ordner. Die Folge war ein nur noch halb funktionierendes Visual Studio. An die Testprojekte dachte ich damals nicht mehr.

Revival

Irgendwann stieß ich auf eine Buchempfehlung und kaufte mir „Kent Beck – Test-Driven Development ‘by Example’“. Und da machte es dann „klick“. Ich begann wieder unit tests einzusetzen, fing auch zaghaft an TDD in Produktivprojekten einzusetzen.
Von einer „Offenbarung“ zu sprechen wäre hier ein wenig theatralisch, aber es machte mir Freude es einzusetzen. Viele nervige Kleinigkeiten wurden auf einmal so simpel.
Zur Verdeutlichung setze ich gerne das Beispiel mit einer Methode zum Testen auf gültige E-Mailadressen ein. Vor den unit tests baute ich eine Methode, startete die GUI und testete mit ausgedachten Testfällen z. B. in einer Textbox. Die Testfälle speicherte ich in einer Excelliste. Es war zeitaufwändig und nach dem Erstellen der Methode nutzte man die Liste nicht mehr. Dank der unit tests hatte ich diese Liste dann im Code. Und sie wurde automatisch ausgeführt.
Rentiert hatte sich das Testen der Methode, dann als ein Kollege eine gültige Email nannte, die meine Methode nicht erkannte. Ich erzeugte einen neuen Test, mit der neuen Email. Und tatsächlich, der Test schlug fehl. Ich glaube die Email beinhaltete einen Unterstrich direkt vor dem @ oder so etwas. Nach dem Ändern der Expression waren ALLE Test grün. Daher wusste ich, dass die Methode nun alle alten und auch die neue Email korrekt erkennen würde. Ich war FERTIG. Keine Notwendigkeit, die Anwendung zu starten. Keine Notwendigkeit eine Liste mit X Emails via copy & paste in ein Textfeld zu kopieren.
DAS war der Moment, in dem mich unit tests in ihren Bann gezogen hatten.

Der Alltag

Nun hat man auch mit unit tests nicht immer solche motivierenden Erlebnisse, aber es gibt genügend Fälle in denen mir Tests das Leben vereinfachen. Es mag ja Beethovens geben, die immer sofort die richtigen Quelltexte runtertippen, aber ich gehöre leider nicht zu denen. Im Alltag sichere ich if statements z. B. gerne gegen „off by one“ Fehler ab. Ich überlege, welche Grenzfälle es gibt, schreibe die Tests und mache mich dann an die Methode. Dank der Code Coverage Anzeige von NCrunch sehe ich auch gleich, an welcher Stelle der aktuelle Test fehlschlägt. Und sind alle Bereiche, wie ich es erwarte abgedeckt? Die Arbeit mit unit tests fühlt sich professioneller an. Es ist nicht mehr ein Tapsen in der Dunkelheit. Sondern ein gezieltes Modellieren des Quelltextes in die geplante Richtung. Hier wird man dann oft belächelt. Man mache sich doppelte Arbeit. Oder „ich programmiere seit 20 Jahren und weiß schon was ich tue“. Aber dabei lächele ich dann freundlich und nicke. Auf lange Sicht gewinnt der getestete Code. Immer.

Fazit

Diese Reihe ist ein wenig melancholisch. Hätt ich mal.
Nicht zurückschauen, sondern nach vorne! Aber gerade an Tagen, wo man aktuell vor einem Problem steht, was durch eine Entscheidung in der Vergangenheit negativ beeinflusst wurde, ist das schwierig.
In solchen Situationen versuche ich mich dann immer darauf zu konzentrieren es jetzt besser zu machen. Ändern kann ich es eh nicht mehr.
Nutzt DU unit tests? Wenn nicht, bist Du wirklich 100 %ig sicher, dass Du sie nicht brauchst?