 |
(14.01.04 19:59)
Als ich vor ein paar Jahren angefangen habe, meine schlechten Angewohnheiten aufzugeben und Unit-Tests zum festen Bestandteil meiner Entwicklertätigkeit gemacht habe, hat sich die Art, wie ich Software schreibe, grundlegend geändert. Viele meiner "frühen" Unit-Tests sind rückblickend betrachtet zwar schlecht und unterscheiden sich ziemlich stark von Tests, die ich heute schreibe. Doch stieg die Qualität meines Codes merklich.
Dominierten am Anfang noch Tests, die lediglich einzelne Methoden auf korrektes Verhalten prüfen, schreibe ich heute viel mehr protokoll-orientierte Tests, die typische bzw. kritische Verwendungsszenarien testen. Aber auch meine Entwürfe haben sich mit dem und durch das Testen stark verändert: Schnittstellen spielen eine zentrale Rolle und gegenüber früher sind die Klassen wesentlich kompakter geworden.
Ein Problem tauchte jedoch immer wieder auf: Bestimmte Klassen schienen sich aus Gründen, die ich anfangs nicht erkannte, regelrecht gegen das Testen zu wehren. Nach einigem Nachdenken, erkannte ich dann, woran das lag: Bestimmte Dinge, die ich auf einem Objekt testen wollte, spielten sich in dessen Inneren ab und liessen sich von aussen ja gar nicht beobachten. Ich begann daher, die betroffenen Klassen so umzuarbeiten, dass sie mit meinen Tests zusammenarbeiten konnten; eine lausige Idee, wie ich heute weiss.
Nun war ich nicht der einzige, der dieses Problem hatte und - nicht erstaunlich - war jemand anderer schlau genug, eine Lösung für dieses Problem zu finden: Mock-Objekte. War bereits das konsequente Unit-Testing eine kleine Sensation für mich, so hat sich meine Arbeit durch den Einsatz von Mocks noch drastischer geändert. Heute kann ich dank des Einsatzes von Mock-Objekten selbst komplexeste Szenarien testen, die ich früher für untestbar hielt; so kann ich z.B. mit Hilfe von Mocks überprüfen, ob das OUT ein Objekt korrekt erzeugt und wieder zerstört.
Das wirklich Bemerkenswerte an Mock-Objekten ist, dass sie zu guten objekt-orientierten Entwürfen zwingen, die auf lose gekoppelten über Schnittstellen interagierenden Objekten beruhen. Diese Objekte sagen einander, was zu tun ist, anstatt sich gegenseitig Löcher in den Bauch zu Fragen, um dann Dinge zu tun, die das gefragte Objekt besser selbst gemacht hätte. Und auch in meinen Tests bin ich nicht mehr darauf angewiesen, meine Objekte um jeden Preis ihre Geheimnisse zu entlocken, denn mit einem Mock teste ich wesentlich besser und flexibler von innen - aus dem Bauch des Objektes heraus.
Heute kann ich mir meine Arbeit ohne Mock-Objekte nicht mehr vorstellen. Sie sind ein sehr wertvolles Werkzeug in meinem Werkzeugkasten und tragen - zumindest an sonnigen Tagen - dazu bei, dass ich die Hoffnung nicht aufgebe, eines Tages fähig zu sein, richtige Software zu schreiben.
-nemo :-)
|
|
