Dieser Bericht kommt etwas später, da ich gestern keine Zeit hatte, einen Post zu verfassen. Die Reflektion habe ich schon durchgeführt, nur eben ohne Keyboard unter den Fingern.
Zunächst hatte ich mir nur vorgenommen, meine Commitrate weiterhin hoch zu halten, aber im Laufe des Tages wurde DRY ein Thema. Meine Haupttätigkeit war das Erstellen eines Modells für die Persistenz mit NHibernate.
Das hört sich zunächst nach einer relativ schwierigen Tätigkeit an, um DRY zu verletzen. Wäre es auch, wenn da nicht die Tests wären: Ich teste jede Klasse grundsätzlich, ob alle (halb-)öffentlichen (public und protected) Properties persistiert werden, um auszuschließen, dass eine Property beim Mapping vergessen wurde.
Diese Tests gleichen sich bei den Klassen strukturell sehr stark:
- Objekt erzeugen
- Objekt persistieren
- Id auslesen
- Objekt aus Session-Cache entfernen
- Objekt mit Id erneut laden
- Die Objekte Property für Property per Reflection vergleichen
Bei der ersten Klasse habe ich das so geschrieben, bei der zweiten kopiert, gepastet und … nachgedacht: Da war doch was. So schnell kann man in die Clipboard-Falle gehen.
Also habe ich den Test in eine generische, abstrakte Basisklasse ausgelagert. Die einzige Operation, die bei jeder gemappten Klasse unterschiedlich ist, ist das Erzeugen des zu speichernden Objekts. Aber dafür gibt es schließlich abstrakte Methoden.
Was habe ich dadurch gewonnen? Schließlich ist es nur Testcode… ;-)
Spass beiseite, ich bin der Meinung, dass auch auf Testcode die ganze Breitseite von Clean-Code-Techniken angewandt werden muss. Schließlich sind zumindest bis zur Produktivnahme die Tests der am häufigsten ausgeführte Code der Anwendung.
Zumindest wenn man TDD und CI verwendet…
Keine Kommentare:
Kommentar veröffentlichen