Ein Mock-Objekt hilft beim Integrationstest, Teile eines Software-Systems zu ersetzen bzw. zu simulieren, solange bis diese Teile schrittweise dem System hinzugefügt werden.
Lesen Sie in diesem Artikel, wie sich Mocks von Dummies und Stubs unterscheiden und ob Sie ein Mock-Objekt auch verifizieren müssen.
Mock-Objekt, Dummy, Stub
Zahlreiche Begriffe kursieren in diesem Kontext. Man unterscheidet meist abhängig von der implementierten Funktionalität folgende Begriffe:
- Ein Stub repräsentierte den „dümmsten“ Vertreter in dieser Liste. Er verfügt über kaum Funktionalität und wird v.a. als Platzhalter genutzt.
- Ein Dummy (kennen Sie vielleicht von Crash-Tests) ist schon etwas klüger und implementiert beispielsweise eine sehr vereinfachte Version des ersetzen Objekts.
- Die Mocks enthalten die meiste Funktionalität. Ein Mock-Objekt enthält meist Code für Testzwecke, beispielsweise prüft es, ob übergebene Parameter im erwarteten Wertebereich liegen, oder es gibt falsche Werte zurück, um das Testobjekt daraufhin untersuchen zu können, ob es damit umgehen kann.
Wie ein Mock-Objekt beim Testen helfen kann
Voraussetzung für Top-Down-Integrationstests
Die IEC 62304 verlangt, dass Sie eine Integrations-Strategie für Ihre Software-Tests bestimmen und dann die Intergrationstests entsprechend durchführen. Wenn Sie eine Top-Down-Integration planen, d.h. wenn Sie zuerst die oberen und dann die unteren Schichten Ihrer Software testen möchten, benötigen Sie Stellvertreter-Objekt wie die oben genannten: Stubs, Dummies und Mock-Objekte.
Mock-Objekte zum Testen der Schnittstellen
Wenn Sie eine Komponente mit Testtreibern testen, testen Sie v.a. die Reaktion dieser Komponente auf Aufrufe mit dem Testtreiber (in folgendem Bild auf der linken Seite).
Wenn Sie hingegen Mock-Objekte einsetzen, können Sie zusätzlich prüfen,
- ob ein Aufruf mit dem Testtreiber auch die erwarteten Methodenaufrufe „auf der Rückseite“ (hier zur Komponente B) erfolgen und
- ob die Komponente A mit den Rückgabewerten der Komponente B richtig umgeht, beispielsweise sich bei ungültigen Rückgabewerten wie spezifiziert verhält.
Bild zum Vergrößern anklicken
Dazu implementiert man in den Mock-Objekten Funktionalität, die zum einen die Aufrufparameter protokollieren und zum anderen einstellbare Rückgabewerte erzeugen kann.
Regulatorische Anforderungen an Mock-Objekte
Zuerst ist festzustellen, dass es keine regulatorischen Anforderungen gibt, überhaupt Mock-Objekte einzusetzen. Schwieriger zu beantworten ist die Frage, ob es regulatorische Forderungen gibt, falls man mit einem Mock-Objekt arbeitet.
Ein Mock-Objekt ein Messwerkzeug
Wenn Sie ein Mock-Framework einsetzen, mit denen Sie Mock-Objekte (automatisiert) erzeugen können, dann ist dieses Werkzeug ein Mess- oder Prozesswerkzeug, das Sie validieren müssen. Beispiele für solche Mock-Frameworks im Java-Bereich sind
Welche Anforderungen die Regularien an Messwerkzeuge und Prozesswerkzeuge stellen und wie Sie diese erfüllen können, lesen Sie in einem weiteren Artikel.
Ein Mock-Objekt kein Messwerkzeug
Wenn Sie hingegen für eine Komponente oder Klasse ein spezifisches Mock-Objekt schreiben, in dem Sie beispielsweise ein gemeinsames Interface implementieren, dann wäre dieses Mock-Objekt Teil Ihres Test-Codes. Solch einen spezifischen Test-Code müssen sich nicht validieren.
Wie wollten Sie das auch tun? Mit Software-Tests, die selbst wieder zu validieren sind? Sie ahnen, wo das endet.
