Donnerstag, 21. November 2013

Mock Object by Example

Bisher wurde gezeigt, wie nicht relevante Abhängigkeiten mittels Dummies eliminiert, spezielle Testvorraussetzungen mittels Stubs geschaffen und indirektes Verhalten mittels Spies geprüft werden kann. Allen diesen Test Doubles gemein ist, dass zusätzlicher Implementierungsaufwand notwendig ist. Oftmals müssen erst neue Interfaces geschaffen und davon spezielle Implementierungen abgeleitet werden.

Mock-Objekte hingegen werden durch ein Mock-Framework erzeugt. Vorhandene Klassen werden ohne eigenen Implementierungsaufwand durch Mock-Objekte ersetzt. Es muss noch nicht einmal ein zusätzliches Interface geschaffen werden, weil das Mocking auch auf Klassen funktioniert. Lediglich das JAR des gewählten Mock-Frameworks muss in den CLASSPATH eingebunden werden. Weiterhin erlauben Mock-Objekte von Hause aus eine Verhaltensverifikation wie bei Test Spies.

Um die o.g. Möglichkeiten von Mock-Objekten zu zeigen, wird das Beispiel um die Anforderungen aus dem Stub- und dem Spy-Test erweitert. Also es erfolgt eine Benachrichtigung des Warenwirtschaftssystems und zur HappyHour kostet alles nur die Hälfte.



Als Mock-Framework wird hier Mockito verwendet. Es stehen mit JMock, EasyMock u.a. weitere Alternativen zur Verfügung, die aber nicht Gegenstand dieser Betrachtung sein sollen. Mockito bietet die Möglichkeit des Mockens von Interfaces oder Klassen über Annotationen oder die statische Methode "mock(Mocked.class)". Bei der hier verwendeten Annotation müssen die annotierten Klassen noch initialisiert werden. Das geschieht wie im Beispiel mit dem mitgelieferten "MockitoJUnitRunner" oder einem Aufruf von "MockitoAnnotations.initMocks(testClass);" im Setup der Klasse.

Nachfolgend sind die drei Test Doubles "Dummy", "Stub" und "Spy" mittel Mock-Objekt dargestellt. Wichtig ist für die Schaffung der Testvorraussetzung für die Happy Hour, dass dem Mock-Objekt mittels "when(Objekt.Methode).thenReturn(Result)" das gewünschte Verhalten mitgeteilt wird. Für die Verhaltensverifikation ist kein zusätzlicher Aufwand notwendig. Es reicht der Aufruf der verify()-Methode.



Somit stellen Mock-Objekte eine Art Allzweckwaffe beim Unit-Test dar. Wie intensiv diese genutzt werden sollte, wurde nicht untersucht. Aber ihr Einsatz gestaltet sich derart einfach, dass eine saubere Trennung von Unit- und Integrationstest auf jeden Fall erreicht werden kann. Jetzt ist es nur noch eine Frage der klaren Verantwortlichkeit des jeweiligen Test. Aber die kann einem kein Framework der Welt abnehmen.

Keine Kommentare:

Kommentar veröffentlichen