Mocks

Ein Unittest macht sich zur Aufgabe, ausschließlich eine Unit, also beipielsweise eine Klasse oder eine Methode zu testen.
Alles, was darüber hinausgeht, muss nicht durch eben diesen Unittest getestet werden.

Nun werden aber sehr häufig andere Methoden anderer Klassen durch die zu testende Methode der zu testenden Klasse aufgerufen.
Meist können diese Methoden bzw. die dazugehörigen Objekte nicht ohne Weiteres für den Test erzeugt oder instanziiert werden.

Dies ist aber auch nicht nötig, so dass man statt den real existierenden Objekten auch Attrapen bauen könnte, die geeignetes Verhalten simulieren.

Im einfachsten Fall braucht man auch keine echte Waschmaschine, sonderen lediglich einen gleich großen Pappkarton, um zu testen, ob der Platz in der Waschküche ausreicht.

Diese Attrapen nennt man Mocks.

Zugegeben, es gibt eine Menge anderer Begriffe, die ähnliche Bedeutung haben könnten:

• Dummies
• Fake
• Stub

Wenn wir aber Objekte für unseren Test konstruieren wollen, die ein gewisses Verhalten simulieren, das als Input für uner zu testendes Objekt dient und gegebenenfalls auch verifizieren wollen, dass und wie diese Methoden des Objekts aufgerufen werden, so ist die derzeit gängige Begriffsbezeichnung eben Mock.

Manchmal lassen sich Testobjekte, die als Input dienen auch einfach direkt mit dem new-Operator oder einer geeigneten Factory erzeugen. Dann spricht man von Dummies. Eine Verifikation findet hier nur im geänderten Zustand des Dummies statt und nicht in der Prüfung aufgerufener Methoden.

Ein Stub dient ausschließlich zur Bereitstellung teil implementierter Methoden, wobei die Implementierungen meist sehr rudimentär und pragmatisch sind, so dass sie als spezifischer Input für das Testobjekt dienen und damit ein bestimmtes Testszenario widerspiegeln. Die Implementierung des Stubs wird also so gesetzt, dass ein bestimmter Testfall damit durchlaufen wird. Durch die gewählte Implementierung wird also ein Testszenario injiiziert.

Ein Fake hingegen ist die Verwendung eines meist leichtgewichtigeren Ersatzobjekts als Abhängigkeit des Testobjekts, das sich in sich geschlossen so verhält wie die eigentliche Abhängigkeit ohne direkt Einfluss auf das Testszenario zu nehmen. Ein Beispiel hierfür wäre die Verwendung einer In-Memory Datenbank wie hsqldb anstatt des produktiven relationalen Datenbankmanagementsystems.