Der Begriff Mock-Objekt leitet sich ab aus dem Englischen mock, was mit scheinbar übersetzt werden kann. Im Software-Engineering wird der Begriff im Zusammenhang mit dem automatisierten Test objektorientierter Software im Rahmen sogenannter Unit-Tests verwendet. Dabei bildet ein Mock-Objekt das Verhalten eines realen Objektes nach. Mock- Frameworks wie beispielsweise JMock, EasyMock oder RMock können Mock- Objekte für einen bestimmten Typ wie Interfaces oder Klassen dynamisch erzeugen. Ein interessanter Ansatz ergibt sich mit dem Framework VirtualMock, was Aspekt-orientiert arbeitet.
Unit-Tests bezeichnen Teile eines Testprogramms und sind per Definition immer feingranular, da sie sich auf den Test einzelner Methoden oder Komponenten beschränken. Dabei werden Unit-Tests im Rahmen der Softwareentwicklung so in den Programmcode integriert, dass Fehler frühzeitig erkannt werden können. Typische Beispiele für die Anwendung von Unit-Tests sind die Anbindung einer Geschäftslogik an eine Datenbank oder das automatisierte Testen von Eingabemasken. Solche Tests mit realen Datenbanken oder Objekten hinsichtlich der geforderten Funktionalität wären zu komplex und aufwändig. An dieser Stelle werden Mock-Objekte eingesetzt, um Zustände und Situationen zu generieren, die die Anforderungen simulieren.
Bezeichnung von Mock-Objekten
In der Literatur werden Mock-Objekte auch häufig mit Rumpf- Implementierungen von Methoden, sogenannten Stubs, verglichen. Mock-Objekte können allgemein formuliert aber Software-Komponenten sein, die wiederum zum Testen andere Komponenten wie beispielsweise eine Datenbank komplett ersetzen.
Mock-Objekte können dynamisch durch Mock-Frameworks wie JMock, EasyMock, RMock oder DynaMock generiert werden. Wiederum erzeugen andere Mock-Frameworks wie MockCreator neuen Programmcode. Mit dem dynamischen Ansatz verbindet sich der Vorteil, keinen neuen Programmcode generieren zu müssen. Jedoch kann sich die Erzeugung von Mock-Objekten immer nur in dem Rahmen bewegen, wie es durch die entsprechende API - beispielsweise die Java-Reflection-API - möglich ist. Darüber hinaus können durch die Verwendung von Frameworks spezielle Testfälle dafür spezifiziert werden, welche Aufrufe von Methoden für ein Mock-Objekt erwartet werden oder welchen Wert das Mock-Objekt bei dem Aufruf einer bestimmten Methode zurückgeliefert werden soll.
Der praktische Einsatz von Mock-Objekten muss immer von folgenden Voraussetzungen getragen sein:
- ein Mock-Objekt und sein Original-Objekt müssen immer im selben Kontext verwendet werden,
- das Mock-Objekt wird nur in der Test- Phase eingesetzt und muss anschließend auf einfachem Wege wieder neutralisiert werden können.
Mock-Objekte bei aspektorientierte Programmierung
Auch im Zusammenhang mit aspektorientierter Programmierung können diese Vorbedingungen einfach erfüllt werden. Dazu muss der Tester den Aufruf von Methoden des durch ein Mock-Objekt zu ersetzenden realen Objektes im Rahmen von sogenannten Point-cuts abfangen und durch Methoden ersetzen, die auf den Testfall abgestimmte Resultate zurückliefern. Dabei muss das reale Objekt keinesfalls schon vollständig implementiert sein, es wird gänzlich durch das Mock-Objekt simuliert. Die zu ersetzenden Methoden für den zu untersuchen Testcase müssen jedoch im Rumpf implementiert sein, sonst kann der Code nicht compiliert werden.
Sofern der Testcase nun initiiert wird, wird der Mock-Aspekt auf seinen initialen Wert gesetzt, der das Verhalten nachbildet, was für den Testcase benötigt wird. Nach dem Verlassen des Testcases wird die korrekte Ausführung des Aspektes aus Sicht des aufrufenden Objektes überprü ft - wurden die richtigen Methoden, in der beabsichtigten Reihenfolge, mit den korrekten Parametern aufgerufen. Dabei werden auch Abweichungen registriert. Für die Durchführung dieser Schritte gibt es unterstützende Werkzeuge - wie beispielsweise das Framework VirtualMock - so, dass Kenntnisse der aspektorientierten Programmiersprachen zwar hilfreich aber nicht unbedingte Voraussetzung sind.