Andreas Aschauer von CodeForce referiert über sein Spezialgebiet “Test Driven Development”. Endlich hält der moderne “Test before Code” Ansatz auch in der SharePoint-Entwicklung Einzug.
Ein überraschendes Erkenntnis der Umfrage im Saal: Test Driven Development in der Entwicklergemeinde
noch nicht weit verbreitet.
Was ist TDD (Test Driven Development)?
Vor der eigentlichen Codierung werden anhand der Anwendungsfälle die Tests geschrieben. Diese Tests sind für Entwickler gedacht, um während der Codierungsphase des Produktivcodes sofort Feedback zum Verhalten des Codes zu erhalten. Da die Tests möglichst kurz gehalten sein sollten, ergeben sich kurze Entwicklungszyklen. Realisiert wird dies durch Unit Tests.
Andreas Aschauer bei der Erklärung des Development-Ablauf
Kosten-Nutzen Relation
Es entsteht zusätzlicher Aufwand (Entwicklung der Tests) der nicht direkt im Zusammenhang mit dem produktiven Ziel der Anwendungsentwicklung steht. In der Anfangsphase des Projekts entsteht extrem
hoher Aufwand, der sich erst im weiteren Fortschritt des Projektes rentiert. Die Einsparungen werden bei Erweiterungen gut sichtbar. Nach einer Erweiterung des Codes ist es leicht möglich zu kontrollieren ob die Anwendung noch das gewünschte Verhalten zeigt, da nur die bereits zuvor erstellten Tests durchlaufen werden müssen.
Ein weiterer angenehmer Nebeneffekt ist, dass TDD zu einer besseren Architektur des Codes führt, da alles modular aufgebaut sein muss.
TDD in SharePoint
Das größte Problem innerhalb von SharePoint ist die Tatsache, dass die SharePoint Objekte keine Interfaces implementieren. Und daher nur mit einem echten SharePoint System im Hintergrund getestet werden können.
Eine Lösung hierfür bietet das kostenpflichtige Produkt “TypeMock Isolator”, das auch vom Microsoft patterns & practices Team für SharePoint Entwicklung empfohlen wird.
Im Code stellt jedes verwendete SharePoint Objekt eine Herausforderung für den Testcode dar. Alle Abhängigkeiten (SPWeb, SPItem, SPList,…) müssen ersetzt werden. Hier hilft TypeMock durch Funktionen die Mock-Objekte erstellen.
mit:
Isolate.Fake.Instance<SPWeb>()
erhält man ein Mock Objekt von SPWeb. Durch weitere Parameter kann definiert werden ob ein Methodenaufruf vom Originalobjekt abgearbeitet werden soll oder von dem Mock-Objekt. Wird der Aufruf vom Mock-Objekt abgearbeitet, so muss noch ein Rückgabewert für die Methodenaufrufe definiert werden. Damit können sämtliche SharePoint Objekte durch Mock-Objekte ersetzt werden und deren Verhalten genau definiert werden. Außerdem ist man vom SharePoint System unabhängig und kann die Tests auf einem System ohne SharePoint Server laufen lassen. Weitere CodeBeispiele, die die weitere Test-Programmierung mit TypeMock demonstrieren sind im Downloadbereich der Konferenz zu finden.
Für jeden Developer der in seinen SharePoint Projekten die Möglichkeit hat TDD einzusetzen sollte sich mit TypeMock auseinandersetzen. Jedoch muss auch klar sein, dass zu jeder Funktion im produktiven Code eine Test-Funktion geschrieben werden muss. Dies führt sehr schnell zur doppelten Anzahl an Codezeilen. Spätestens nach der ersten Erweiterung der Projektes ist man froh Testen zu können und der zusätzliche Aufwand hat sich gelohnt.
War ein wirklich spannender Einblick in Test Driven Development unter SharePoint!
Martin Groblschegg, live von der SharePoint Konferenz Wien
www.component-software.at