Wer schon mal versucht hat, einen Unit Test für SharePoint zu schreiben, wird festgestellt haben: Die Abhängigkeit zum SharePoint Server bekommt man nicht weg, was aber eines der Grundprinzipien beim Unit Test ist. Bisher war es notwendig auf Drittanbieter Tools wie z.B. TypeMock auszuweichen.
Als Alternative bot Microsoft Research im Projekt “Pex & Moles” mit Moles eine Mockinglösung (Moles). Das erfreuliche: Seit Visual Studio 2012 ist Moles nun Bestandteil des Visual Studios. Unter dem Namen “Fakes Framework” wurde Moles nun in den regulären Support aufgenommen. Leider ist es nur in der Ultimate Edition enthalten.
Das Grundprinzip
Ein simpler Aufruf von System.DateTime.Now bereitet einem Unit Test Probleme. Das erwartete Ergebnis wird wohl im nächsten Jahr ein anderes sein, als zum Zeitpunkt der Testerstellung. Die beste Lösung ist es, im Design der Anwendung bereits Vorkehrungen für einen Test zu berücksichtigen. Manchmal steht man jedoch vor dem Problem, dass das Design nicht mehr geändert werden kann und dennoch Tests erstellt werden müssen. SharePoint ist so ein Fall 
. Hier wurde auf Testbarkeit nicht viel Wert gelegt.
Das Fakes Framework erstellt sogenannte Shim-Klassen in denen jeder Funktionsaufruf durch ein Delegate ersetzt wird. Im Fall eines Properties wird sowohl für Get als auch für Set ein Delegate angelegt.
Ein einfaches Demo
Für den ersten Einstieg empfiehlt sich eine WinForms Anwendung in der in einer Message Box das aktuelle Datum ausgegeben wird. Der Code bedarf keiner Erklärung 
private void button1_Click(object sender, EventArgs e)
{ ZeigeDatum();
}
public void ZeigeDatum()
{ MessageBox.Show(DateTime.Now.ToString());
}
Shim-Klassen können nur innerhalb eines UnitTest Projekts verwendet werden. Innerhalb eines normalen Projektes erhält man die ShimNotSupportedException. Also legen wir zum WinForms Projekt noch ein UnitTest Projekt an und referenzieren auf das WinForms Projekt.
Um Fakes zu aktivieren, bzw die Shim Klassen anzulegen wählt man im Visual Studio im Solution Explorer jenes Assembly aus, von welchem die Shim-Klassen erstellt werden sollen. In unserem Demo ist es “System.dll” Im Kontextmenü wählt man den Eintrag “Add Fakes Assembly”. Danach ist Geduld angesagt. Im Fall der SharePoint.dll dauert das leicht mehrere Minuten. Ob das Visual Studio fertig ist, erkennt man daran, dass ein Kompilieren des Projektes wieder möglich ist. Solange die Shim-Klassen erstellt werden, kann nicht kompiliert werden.
Danach sind weitere Referenzen zu finden. System.4.0.0.0.Fakes und mscorlib.4.0.0.0.Fakes wurden angelegt. Auch gibt es nun in der Solution einen Ordner Fakes. In diesem liegen XML Dateien über die die Fakes-Erstellung gesteuert werden kann. Z.B.. kann definiert werden für welche Klassen eine Shim-Klasse angelegt werden soll, um nicht unnötiger Weise für alle Klassen im Assembly eine Shim-Klasse anzulegen.
Die Testmethode
[TestMethod]
public void TestMethod1()
{ Form1 f = new Form1();
using (ShimsContext.Create())
{ ShimDateTime.NowGet = () => new DateTime(2000, 1, 1);
f.ZeigeDatum();
}
}
ShimsContext.Create()stellt die ShimKlassen bereit. Es empfiehlt sich diese innerhalb eines using aufzurufen, sodass am Ende das Dispose aufgerufen wird. Innerhalb des erstellten Context können wir nun für jede Methode unseren eigenen Code hinterlegen.
Im Fall des Now- Properties, wurde die Methode NowGet angelegt und für diese wird ein neuer Rückgabewert definiert.
Die MessageBox zeigt nun den 1.1.2000
Mit dem Fakes Framework ist es also möglich für jedes Property oder jede Methode einen eigenen Code zu hinterlegen und damit im Unit Testing zu arbeiten.
Teil 2 beschäftigt sich mit SharePoint und folgt nächste Woche.