Softwarequalität durch Unit Testing

Prolog: Ich habe es getan. Ich hatte angefangen, meine komplette Software automatisch zu testen. Hierfür lernte ich JUnit und Mockito und fing an, jede meiner Klassen automatisch zu testen.

Ein tolles Gefühl. Irgendwann jedoch, kam ich nicht wirklich weiter. Der Umfang von JUnit war zu gering.

Ich griff zu anderen, mächtigeren Frameworks und nutzte die Macht der Reflections, um auch in die tiefsten Innereien meiner Klassen zu schauen, meine Objekte zu manipulieren und so auch die verwinkelten Ecken meiner Software testen zu können. Aber auch das bereitete mir Probleme. Immer, wenn ich Änderungen am Code vornahm, oder diesen erweiterte, mussten dutzende von Tests angepasst werden.

Bei jedem neuen Feature wurden die Tests komplexer und komplizierter. Was ein Aufwand! Irgendwann dämmerte es mir: Tests sind schlecht!

Sie kosten viel mehr, als dass sie bringen! Ich schmiss die Tests raus und konnte wieder entspannt programmieren. Gut... die vielen Fehler, die erst spät entdeckt wurden.

OK... die paar Regressionsfehler die ich nicht entdeckte.... Ja... die ständig wieder auftauchenden Fehler über die sich der Kunde wundert... aber sonst? Dann jedoch wurde ich Mitglied eines neuen Teams.

Mit diesem kam eine neue Software in meinen Verantwortungsbereich. Diese hatte eine wunderbare Testabdeckung. Einfache Tests.

Saubere Tests. Leichte Tests. Ich war verwundert.

In diesem Moment war mir klar, es war mein Code, der schlecht testbar war. Tests müssen nicht kompliziert sein. Man muss nur die Konzepte des Testens verstehen.

Ich arbeitete mich in die Konzepte ein. Lernte die Prinzipien des guten Testens. Merkte, wie viel gutes Testen mit sauberem Softwaredesign zu tun hat.

Was eine Freude! Es kribbelte. Ich schrieb Tests.

Wurden sie zu kompliziert, passte ich das Design des Codes an. Meine Tests zeigten mir meine Fehler im Design. Genau das will ich dir vermitteln!