In der Vergangenheit war es nicht immer einfach die von Visual Studio mitgebrachte Möglichkeit für Unit Tests in Verbindung mit SharePoint zu nutzen. In den aktuellen Versionen (SharePoint 2013 und Visual Studio 2013) ist dies einfacher geworden und sollte auch anregen daran zu denken, wenn man SharePoint Apps entwickelt. Gerade wenn man an Auto-hosted Apps denkt, bei denen die Businesslogik außerhalb des SharePoints, in beispielsweise einem Azure Service gehostet wird, sollte man Unit Tests unbedingt nutzen.
Aber nicht nur für SharePoint Apps sind sie eine wichtige Möglichkeit Qualität in eine Lösung zu bringen, sondern auch für die traditionellen (Full-trusted) Lösungen, wie man sie hinlänglich kennt. Unit Tests im Zusammenspiel mit Full-trusted Solutions waren eben mitunter recht schwierig umzusetzen.
Beispielsweise kann man damit einen Unit Test schreiben, um Eventreceiver einer Liste zu testen. Legt man ein SharePoint Projekt an, dann ist es relativ leicht auch ein Unit Test Projekt zu erstellen, um das Ausführen von Eventreceivern zu testen. Geht man von einem Eventreceiver aus, der z.B. ein Datumsfeld setzt, wenn ein neues Item angelegt wird, so braucht man anschließend nur einen Unit Test, der genau diesen Fall überprüft, erstellen.
Folgende Schritte sind aber zuerst notwendig, bevor man loslegen kann:
1. Ein Unit Test Project anlegen
2. Eine Referenz auf das SharePoint Projekt und eine Referenz auf das Microsoft.SharePoint Assembly hinzufügen. In diesem Beispiel handelt es sich um eine Dummy SharePoint Solution namens “DummySPProject”.
3. Die Prozessor-Architektur der Tests auf x64 festlegen.
Hat man diese Schritte ausgeführt, kann man loslegen. Der Unit Test sieht beispielsweise dann so aus:
Führt man den Test anschließend aus sieht man , ob er funktioniert oder nicht.
Ein paar Dinge sollen an dieser Stelle betont werden.
- Es ist klarerweise ein Beispiel, das nur zeigen soll, wie man technisch Unit Tests für SharePoint ausführen kann. Der reale Anwendungsfall des gezeigten Beispiels soll hier auch nur eine untergeordnete Rolle spielen.
- Hier wird ein Eventreceiver getestet, der synchron läuft. Bei asynchronen Eventreceivern ist zu bedenken, dass die Geschäftslogik asynchron abläuft und somit der Test möglicherweise fehlschlägt, wenn der Eventreceiver erst zu einem späteren Zeitpunkt abläuft als der Zugriff des Tests auf das Feld, das den automatisch generierten Wert beinhaltet. Man könnte beim Testen beispielsweise eine Zeit verstreichen lassen oder das besagte Feld mehrmals abfragen (polling), bevor man nach einer verstrichenen Zeit (timeout) einen Fehler feststellt .Möglicherweise existiert auch ein Weg, das Feld asynchron abzufragen. Man denke hier an Remote Eventreceivern, die es seit SharePoint 2013 gibt. Dies hätte aber mit obigen Ansatz der Full-trusted Solution nichts mehr zu tun.
- Für die neue Möglichkeit Lösungen in Form von Apps zu entwickeln, könnte man anstelle des Microsoft.SharePoint Assembly auch die Client bzw. die ClientRuntime Assemblies nutzen, oder überhaupt die Rest Services konsumieren.
- Außerdem wäre auch denkbar Workflows mit Hilfe von Unit Tests zu testen. Klarerweise abhängig davon, was dadurch abgedeckt werden soll. Besonders hier sei nochmal auch die Problematik der asynchronen Ausführung betont und einen möglichen Mechanismus zu berücksichtigen asynchron diese Tests auszuführen.
