Please activate JavaScript!
Please install Adobe Flash Player, click here for download
ePaper created 2014-07-11, 15:49:18 | version 1.32.00
48 T I P P S U N D T R I C K S Unit Testing mit ArcObjects TIPPS UND TRICKS FÜR ENTWICKLER Motivation Unit Testing und ArcObjects sind kein einfaches Unterfangen. Zum ei- nen muss man die Software so aufbrechen, dass eine testfähige Archi- tektur gegeben ist, und zum anderen muss man die Möglichkeiten der ArcObjects kennen, um zu wissen, wie Objekte im Testkontext erzeugt und verwendet werden können. Die erste Herausforderung beantwortet sich durch konsequente An- wendung diverser Architektur-Patterns und -Best-Practices. Allem vor- an steht dabei, dass sich eine Komponente nur einer Aufgabe widmet und deren Methoden alle so kurz wie möglich sein sollten. Damit ergibt sich eine entsprechende Fokussierung, die ihrerseits dedizierter ohne Seiteneffekte testbar ist. Schwieriger zu verstehen ist der Testkontext an sich für ArcObjects. Möchte man beispielsweise eine spezielle Logik auf einem Feature tes- ten, braucht man einen Testkandidaten für ein Feature. Allerdings lässt sich ad hoc ein Feature eben nicht erzeugen, dafür bedarf es beispiels- weise einer Feature-Class, deren Verwendbarkeit an Workspaces ge- koppelt ist. Man sieht: Allein die Erzeugung eines Features verlangt eine ganze Kette an zusätzlicher Logik. Ähnliche Fragestellungen ergaben sich natürlich auch in anderen Um- feldern, sodass sich findige Entwickler Gedanken darüber gemacht ha- ben, wie man am einfachsten derartig benötigte Objekte erzeugt. Dies war die Geburtsstunde sogenannter Mocking Frameworks. Mocking Frameworks Ein Mocking Framework hat die Aufgabe, Mocks zur Verfügung zu stel- len. Mocks gehen dabei über einfache Platzhalterobjekte weit hinaus.1 Sie lassen sich mit einer gewissen Logik unterlegen, deren korrekter Zu- griff von außen protokolliert werden kann. Üblicherweise sind Unit Tests ein statusbasiertes Testen – das heißt, man verifiziert mit Assert-Logik bestimmte Werte nach Ablauf der Logik. Mocks erlauben ein verhaltensbasiertes Testen, bei dem mittels der Zugriffprotokollierung verifiziert wird, ob die zu testende Logik das Ob- jekt so aufruft, wie es für die Richtigkeit zu erwarten wäre. Dazu können die Reihenfolge von Aufrufen ebenso wie die Aufrufparameter geprüft werden. Für die Erzeugung eines derartigen Mocks an sich wird einfach dyna- misch eine entsprechende Instanz des zu mockenden Typen erzeugt. Das funktioniert unter anderem ausgezeichnet für Instanzen von Inter- faces, abstrakten Klassen und ableitbaren Klassen. Alle bekannten Frameworks (Moq2, RhinoMocks3, Dynamic Proxy…) sind dazu in der Lage. Beispiel Zum Testen der einfachen Methode lässt sich das Feature mittels Moq beispielsweise wie folgt erzeugen und übergeben: Je nach Mocking Framework sind die verhaltensbasierten Tests unter- schiedlich scharf zu definieren. Insbesondere die originäre Rhino-Mocks- Record/Replay-Syntax dürfte den ein oder anderen zur Verzweiflung bringen. Allerdings erlaubt diese Syntax auch die fokussiertesten Tests. Die neuere AAA-Syntax bzw. die Moq-Syntax erleichtert den Einstieg in die Mocking-Thematik hingegen ungemein – mit einem gewissen Ver- lust an Kontrolle. Typemock Isolator Typemock Isolator4 ist ein kommerzielles Mocking Framework, das neu- erdings in einer kostenfreien Basic Edition angeboten wird. Der Funkti- onsumfang geht weit über die Fähigkeiten der bisher genannten freien Frameworks hinaus – Beispiele sind die Visual-Studio-Integration oder das Mocken von statischen Artefakten. Isolator greift dazu sehr tief in die .NET-Trickkiste und bedient sich der sogenannten Profiling-API. Da- her ist es diesem Framework möglich, fast jeden Methodenaufruf um- zubiegen und auf eigene Ersetzungen zu lenken. Entsprechende Web- Casts von Isolator bzw. eigene Spielerein kann man ruhigen Gewissens als Augenöffner bezeichnen – sie verändern teilweise grundlegend das eigene Verständnis für die Abläufe in der .NET CLR. Eine der Domänen von Isolator ist das Einführen von Unit Tests in Brownfield-Projekten, deren Architekturen nicht den oben genannten Best Practices folgen. Beispiel In einem unserer SAP-GIS-Integrationsprojekte hatten wir die Aufga- benstellung, unverlinkte Objekte zu identifizieren (also Objekte, die es nur in einer der beiden Welten gab). Dazu war der originale Legacy Code5 aufseiten des GIS: 48