Attrapen und Mocks

Was tun, wenn das zu testende Modul eine kostspielige oder komplexe Ressource benötigt? Führen Sie eine Attrappe ein, die diese Ressource simuliert; das typische Beispiel ist eine Datenbank oder eine Netzwerkressource. Der Einsatz von Attrappen setzt voraus, dass die zu simulierenden Ressourcen in Form von Schnittstellen beschrieben sind. Nur so ist es möglich, die tatsächliche Implementierung transparent durch die Attrappe zu ersetzen, vgl. hierzu auch die Faustregel zum Thema Schnittstellen versus Klassen.

Eine ausgeklügelte Variante der Attrappen sind die sog. Mock-Objekte. Diese simulieren nicht nur die jeweilige Ressource, sondern sie sind auch in der Lage, ihre korrekte Verwendung selber zu überprüfen. Sie bilden eine der mächtigsten Testmuster überhaupt.

Die Verwendung eines Mock-Objekts anstelle der tatsächlichen Implementierung bietet sich in den folgenden Fällen an:

• Das echte Objekt ist schwierig aufzusetzen.
• Das echte Objekt zeigt Verhalten, das schwierig auszulösen ist, z.B. das Auslösen eines Netzwerkfehlers.
• Das echte Objekt hat oder ist eine Benutzerschnittstelle.
• Das echte Objekt ist langsam.
• Der Test muss das echte Objekt fragen, wie dieses verwendet worden ist, z.B. um sicher zu stellen, dass eine bestimmte Callback-Methode aufgerufen worden ist.
• Das echte Objekt existiert noch nicht (vgl. Test-First).

Mock-Objekte holen den Grossteil des Test-Codes zu sich. Dadurch lassen sich Testfälle wesentlich vereinfachen. Mock-Objekte werden in das zu testende Objekt eingeschleust. So wird es möglich, das Objekt von innen zu testen.

Wie testen wir, dass zwei Objekte korrekt miteinander arbeiten? Indem wir das zu testende Objekt mit unserem Testfall kommunizieren lassen anstelle des tatsächlichen Objekts. Der Testfall wird dabei zu einer Miniattrappe.

Wie testen wir einfach, ob eine bestimmte Aufrufreihenfolge befolgt wurde? Indem wir ein Mock-Objekt oder den Testfall als Self Shunt verwenden, der die Methodenaufrufe in einem Log String aufzeichnet und diesen Log String mit der erwarteten Aufrufsequenz vergleicht. Eine noch mächtigere Variante ist die Verwendung eines Loggers, der die strukturierte Protokollierung und Kontrolle der erwarteten und tatsächlichen Methodenaufrufe erlaubt.

Wie testen wir, ob Fehlercode im Fehlerfall korrekt ausgeführt wird? Indem wir eine Attrappe einführen, die den Fehler produziert. Das zu testende Objekt kann dann einfach darauf geprüft werden, ob es korrekt mit diesem Fehler umgeht.

• An Introduction To Endo-Testing... von Sascha Frick.
• Kapitel 6 Unabhängigkeit durch Dummy- und Mock-Objekte im Buch Unit Tests mit Java von Johannes Link
• www.mockobjects.com