Die Thematik “Mocking Frameworks” lässt sich aus verschiedenen Perspektiven betrachten. Um das Thema im vollständig zu erfassen, werden mehrere Artikel zu einer Blog-Serie zusammengefasst. Heute: “Was sind Mocking Frameworks?” Der Artikel geht der Frage auf den Grund: “Wie wähle ich das richtige Mocking Framework?”. Die nächsten Artikel sind der technischen Anwendung und Funktionsweise von Mocking Frameworks gewidmet.
Mocking Frameworks bieten die Rahmenstruktur zur Erstellung, Manipulation und Kontrolle von Mock Objekten. Diese “Mocks” sind Objekte, die das Verhalten von realen Objekten simulieren. Daher kommen Mocking Frameworks im Rahmen der Qualitätssicherung von Software im Bereich des Testing zum Einsatz. Simulierte Teile (Units) der Software werden mit den “Mocks” abgegrenzt, um den Fokus auf den zu testenden Teil (Unit) der Software zu legen.
Zum Beispiel: Eine Software chiffriert Daten mit einem Schlüssel. Um die Verschlüsselung zu testen, sollte es irrelevant sein, woher der Schlüssel kommt. Der Test für die Verschlüsselung sollte ebenfalls weiterhin erfolgreich sein, wenn sich im Produktiv-System der Schlüssel ändert. Das Generieren des Schlüssels wird auf einen fixen Wert gemockt.
Ein Mock könnte wie folgt aussehen:
interface IKey
{
/// <summary>
/// Holt einen Schlüssel
/// </summary>
string GetKey();
}
Mock<IKey> mock = new Mock<IKey>();
mock.Setup("GetKey").Returns("ExampleKey");
Im Artikel wird das Wort “Mock” als Überbegriff für “Fake” und “Stub” verwendet. Alle drei Begriffe stehen für das Abgrenzen von Software Teilen, unterscheiden sich aber in ihrem Verhalten.
Der Fake ist ein Mock, der lediglich den simulierenden Teil der Software in einer vereinfachten Variante zur Verfügung stellt.
Ein Stub enthält im Vergleich zu einem Fake kaum bis keine Logik, aber sammelt meistens Informationen über die simulierten Funktionen der Software, beispielsweise: “Wie wurde die Methode ‚GetKey’?” aufgerufen.
Mocks sind eine Mischung von Fake und Stub. Sie können einen Teil der Software simulieren wie ein Fake und sammeln dabei Informationen wie ein Stub. Darüber hinaus ermöglicht ein Mock dem Test, Erwartungen zu definieren. Beispielweise kann ein Test validieren, dass die Methode ‚GetKey’ nur einmal aufgerufen wird. Ein anderer Test kann den Mock natürlich anpassen, um beispielsweise zu definieren, dass die Methode ‚GetKey’ 10x oder niemals aufgerufen wird.
Einen Grund haben wir vorweg genommen: Unit Tests sind ohne ein Mock der Umgebung meistens nicht möglich, da der zu testende Teil der Software meistens nicht ohne den nicht zu testenden Teil der Software funktioniert.
Unit Tests ermöglichen das Finden von Fehlern und bei Änderungen am Quellcode wird schnell ersichtlich, was alles nicht mehr wie gewollt funktioniert.
Ein weiterer Grund, Mocks zu verwenden ist das spezifizieren von Software. Im Grunde genommen wird die Vorgehensweise umgedreht. Es wird zuerst ein Test erstellt, der ein Unit (Modul) verwendet, das über ein Mock benutzt wird. Nachdem der Test erstellt wurde, wird die Produktiv-Implementierung erstellt/erweitert, um dem Test im Produktivsystem gerecht zu werden. Diese Vorgehensweise findet sich zum Beispiel im Test-Driven-Development wieder.
Das Simulieren der Umgebung kann auch mit einer “normalen” Software Implementierung umgesetzt werden. Es entwickelt sich oft eine Art “Tunnelblick”; für alles werden Mocks erstellt. Wird ein Mock sehr kompliziert, kann es teilweise einfacher sein, eine weitere Testklasse einem Mock vorzuziehen. Außerdem muss beachtet werden, dass das Entwicklerteam mit einem Mocking Framework umgehen kann. Das Entwicklerteam muss am Anfang bei der Testerstellung umdenken und ggf. lernen, mit dem Mocking Framework umzugehen. In kleineren Projekten kann das Benutzen von Mocking Frameworks eine große Investition darstellen.
Die Mocking Frameworks lassen sich unter vielen Aspekten vergleichen. Die wichtigsten Vergleichspunkte sind:
Software, die auf Herz und Nieren getestet wird und somit mit einem guten Gewissen ausgerollt werden kann, wird meistens mittels Mocking Frameworks testfähig gemacht. Es gibt viele verschiedene Mocking Frameworks und es gibt viele Entscheidungskriterien, nach denen ein Mocking Framework ausgewählt werden kann. Das Wissen über diese Frameworks lässt sich erfahrungsgemäß gut auf andere übertragen, somit ist am Anfang nicht entscheidend, welches, sondern eher, dass überhaupt Wissen über Mocking Frameworks im Team vorhanden ist.
Im nächsten Artikel werden wir mehrere Mocking Frameworks für .NET vorstellen und miteinander vergleichen.