Ned auf da Brennsuppm daheagschwumman sein

Copyright: Kronsteiner/PID

Wien ist eine schöne Stadt! Diese Woche konnte ich dort ein dreitägiges Training im Bereich Unittesting halten. Der Start war etwas holprig, denn in keinem der beiden Gebäude wusste jemand etwas von der Schulung. Somit war es nur nach ein paar Telefonaten möglich den richtigen Raum im richtigen Gebäude zu finden. Aber ich hab‘s noch pünktlich geschafft.

Schulung à la carte

Die allgemeine Einführung und die Vorstellung des Frameworks nUnit haben alle Teilnehmer gut gemeistert und auch die verschieden Übungen dazu gingen zügig von der Hand. Also konnten wir noch am ersten Tag ein wenig komplexer weitermachen und uns dem Thema DependencyInjection und dem Framework StructureMap widmen.

Den nächsten Morgen begannen wir mit dem schreiben eigener Fakeobjekte und dann ging es auch schon mit Mocking weiter. Jetzt merkte man den Teilnehmern erste Zweifel an, ob sie das jemals in der Praxis tatsächlich anwenden können. Okay, da wir sehr gut im Zeitplan lagen haben wir kurzerhand die restliche Theorie der Schulung im Schnelldurchlauf behandelt. Dabei blieben natürlich ein paar praktische Übungen sowie die Details auf der Strecke. Dafür sollte der dritte Tag ganz für die Projekte der Teilnehmer da sein. Am Ende des Tages stand noch die testgetriebene Entwicklung auf dem Programm. Als Experiment haben wir die Praxis dazu gleich für alle im Pairprogramming gemacht – eine nette Abwechslung.

Schöner Code macht Tester glücklich

Auf Wunsch der Teilnehmer stand der dritte Tag ganz im Zeichnen von Refactoring und LegacyCode. Mit ein wenig Starthilfe konnten alle Teilnehmer erste Ansatzpunkte in ihren Projekten finden. Es wurden Tests geschrieben, Klassen aufgeteilt, Abhängigkeiten herausgezogen und für den neuen Quellcode Unittests entwickelt. Und die Zweifel bezüglich der Praxis waren fast vollständig verflogen.

Die Teilnehmer haben die Werkzeuge genutzt und das bereits in den eigenen Projekten. In Zukunft sollte der neue Quellcode gleich ein bisschen schöner sein, dann ist der Aufwand für die Unittests nur noch halb so groß. Denn Methoden mit mehr als 1000 Codezeilen fanden die Teilnehmer an Ende selbst zu viel und nicht mehr gut testbar.

Autor

Sebastian Stephan Teamleiter Softwareentwicklung
Sebastian Stephan

Dresden