(04.06.04 07:30)

Das endoskopische Testen mit Hilfe von Mock-Objekten ist eine wertvolle Technik in der testgetriebenen Entwicklung. Es taucht aber immer wieder die Frage auf, was ein Mock genau tut und wie er sich z.B. von einem Stub unterscheidet. Darum hier der Versuch einer kurzen Begriffsklärung:

	Stub: Eine Klasse mit Methoden, die nichts tun. Ein Stub wird verwendet, damit das System compiliert und ausgeführt werden kann.
	Fake: Eine Klasse mit Methoden, die einen festen oder per Programmcode setzbaren Wert bzw. Werte zurück geben können.
	Mock: Eine Klasse, auf der Expectations bezüglich der erwarteten Methodenaufrufe und den entsprechenden Parametern, Aufrufreihenfolge, Anzahl, etc. gesetzt werden können. In der "vollen Ausbaustufe" können je nach Aufrufszenario unterschiedliche Werte zurück geliefert werden. Ganz wichtig, ist die Fähigkeit des Mocks, sich selber auf korrekte Verwendung zu überprüfen. Dabei ist der Mock so umgesetzt, dass er sofort meldet, wenn er nicht wie erwartet verwendet wird. Dadurch wird es wesentlich einfacher Fehler zu entdecken, da der Fehler nicht erst am Schluss des Tests auftritt. Die Verifiy-Methode des Mock prüft dann "nur noch" abschliessend, ob z.B. alle erwarteten Aufrufe in der richtigen Anzahl erfolgt sind.

Der "echte" Mock holt somit einen Gorssteil der Testfunktionalität zu sich und wird damit zu einer wohl definierten Einheit der Wiederverwendung von Testfunktionalität für bestimmte Schnittstellen und Protokollinteraktionen.

Wichtig, obwohl wir das ja alle wissen: Der Einsatz von Mocks sollte sorgfältig erfolgen und vorallem müssen die Mocks einfach bleiben. Wenn wir das Bedürfnis verspüren, den Mock zu testen, dann haben wir definitv ein Problem. Wir müssen auch sorgfältig darauf achten, dass die Zahl der für einen Tests benötigten Mocks überschaubar bleibt; mehr als drei Mocks sollten es nicht sein, sonst steht zu vermuten, dass die zu testende Klasse zu wenig schüchtern ist. Und manchmal lohnt es sich, ganz auf einen Mock zu verzichten und dafür eine echte Implementierung als Collaborator zu verwenden. Über die öffentliche Schnittstelle dieses Collaborators kann man dann aus dem Test heraus prüfen, ob die zu testende Klasse diesen korrekt verwendet hat. Es ist also nicht immer nötig, für jeden Collaborator einen Mock zu schreiben, um anständig testen zu können.

-nemo :-)

Über diesen Artikel diskutieren.

Zugriffe heute: 1 - gesamt: 309.