Mocking und Test-Doubles

In L6 hast du Unit-Tests in JUnit und pytest schreiben gelernt. Aber: ein Unit-Test soll isoliert sein. Was, wenn deine Klasse von einer Datenbank, einem E-Mail-Service oder einer Wetter-API abhängt? Diese externen Abhängigkeiten machen Tests langsam, instabil und teuer.

Die Lösung: Test-Doubles – Stell-Vertreter, die die echten Abhängigkeiten ersetzen. Die berühmteste Form heißt Mock, aber es gibt fünf verschiedene Typen, die in Klausuren gerne durchgemischt werden: Dummy, Stub, Spy, Mock, Fake. Diese Lektion entwirrt sie sauber.

1) Das Problem: echte Abhängigkeiten im Unit-Test

Stell dir vor, du willst eine Klasse OrderService testen. Sie ruft beim Bestellen einen E-Mail-Service auf, um eine Bestätigung zu schicken. Ohne Test-Doubles würde dein Test:

Tatsächliche E-Mails verschicken (Spam an den Kunden bei jedem Testlauf!).
Vom E-Mail-Server abhängen (außer Betrieb → roter Test).
Sekunden statt Millisekunden brauchen.
Nicht den OrderService testen, sondern die ganze Kette.

Echte Abhängigkeit vs. mit Mock

Der Mock ersetzt die echte Abhängigkeit. Er hat dieselbe Schnittstelle, tut aber innen nichts (oder etwas Vorhersehbares). Der zu testende Code merkt nichts davon. So bleiben Tests schnell, deterministisch und auf das Wesentliche fokussiert.

2) Test-Double – der Überbegriff

Test-Double ist die englische Übersetzung von „Filmstunt-Double" – der Stellvertreter, der die gefährliche Szene übernimmt, damit der echte Schauspieler unversehrt bleibt. Genau das tun sie im Test: sie übernehmen die Rolle einer realen Abhängigkeit.

Die berühmte Klassifikation von Gerard Meszaros unterscheidet fünf Typen. Sie werden gerne synonym verwendet, sind aber technisch verschieden:

3) Die fünf Test-Double-Typen im Detail

Dummy, Stub, Spy, Mock, Fake

1. Dummy tut gar nichts

Ein Platzhalter, der nur deshalb existiert, weil der Methodenaufruf einen Parameter verlangt. Wird im Test nicht benutzt. Beispiel: ein Dummy-Logger als Konstruktor-Parameter einer Klasse, der im Test sowieso nichts loggen soll.

// Java Logger dummy = null; // einfachster Dummy OrderService s = new OrderService(dummy); // "null" wird im Test nie aufgerufen

2. Stub gibt fest verdrahtete Antworten

Ersetzt eine Abhängigkeit durch vorhersagbare Rückgabewerte. Stellt sicher, dass der Test in einen bestimmten Pfad geht. Beispiel: ein Wetter-Stub, der immer „sonnig" zurückgibt.

when(weatherApi.getWeather()).thenReturn("sonnig"); // Egal was passiert, der Stub sagt immer "sonnig"

3. Spy protokolliert Aufrufe

Ein echtes Objekt, aber mit Aufrufprotokoll. Du kannst nachher prüfen, wie oft und mit welchen Argumenten Methoden aufgerufen wurden. Verhalten echt, Beobachtung künstlich.

EmailSpy spy = spy(new EmailService()); service.placeOrder(...); verify(spy, times(1)).send(eq("test@x.de"), anyString());

4. Mock kombiniert Stub + Erwartung

Das prominenteste Test-Double. Vereint vorhersagbare Antworten (wie Stub) und Erwartungsprüfung (wie Spy): „Beim Test wird die Methode 'send' mit der Adresse 'x' aufgerufen werden – sonst fail". Werkzeuge: Mockito (Java), unittest.mock (Python), Sinon (JS).

EmailMock mock = mock(EmailService.class); when(mock.send(anyString(), anyString())).thenReturn(true); service.placeOrder(...); verify(mock).send("kunde@x.de", "Bestätigung");

5. Fake funktioniert echt, aber einfach

Eine vereinfachte, aber echt funktionierende Implementation. Klassiker: eine In-Memory-Datenbank statt der echten – funktioniert wie eine DB, aber nur im RAM, ohne Datei. Komplexer aufzubauen als andere Doubles, aber realitätsnaher.

// Statt echter PostgreSQL: H2 in-memory UserRepository fake = new InMemoryUserRepository(); fake.save(new User("Anna")); // echte CRUD-Logik, nur RAM-only

Im Alltag wird oft alles „Mock" genannt – Mockito heißt ja auch so. Streng nach Meszaros sind aber die fünf Typen klar getrennt. Für die IHK-Klausur: Dummy = ungenutzt, Stub = Antworten zurück, Spy = Aufrufe loggen, Mock = Erwartungen + Antworten, Fake = vereinfachte echte Implementation.

4) Vergleich auf einen Blick

Die fünf Typen tabellarisch

Typ	Rückgaben?	Aufrufe loggen?	Echte Logik?	Klassischer Einsatz
Dummy	–	–	–	Pflicht-Parameter, wird nie benutzt
Stub	✓	–	–	Pfad-Auswahl, festgelegte Antworten
Spy	✓	✓	✓ (echt)	echtes Objekt + Aufrufprotokoll
Mock	✓	✓	–	Erwartungen prüfen
Fake	✓	–	✓ (vereinfacht)	In-Memory-DB, Test-Auth

5) Stubs vs. Mocks – die feine Linie

Die wichtigste Unterscheidung in Klausuren: Stub ist auf Eingabe fokussiert („was kommt zurück?"), Mock auf Ausgabe („was wurde aufgerufen?").

Beispiel anhand des OrderService:

Stub-Test: „Wenn der Inventory-Stub 0 Stück zurückgibt, dann wirft OrderService eine OutOfStockException." – Stub gibt einen Wert vor, Test prüft Verhalten des SUT.
Mock-Test: „Beim Aufruf von placeOrder soll der E-Mail-Mock genau einmal mit der richtigen Adresse aufgerufen werden." – Mock prüft, dass eine bestimmte Aktion stattfindet.

Stubs sind state-based: prüf den Endzustand. Mocks sind interaction-based: prüf die Interaktion.

6) Mock-Frameworks im Vergleich

Niemand baut Mocks von Hand – dafür gibt es spezialisierte Libraries:

Mock-Libraries je Sprache

Mockito (Java)

Der De-facto-Standard. mock(), when().thenReturn(), verify(). Spring-Integration top.

unittest.mock (Python)

Eingebaut in Python ab 3.3. MagicMock(), patch(). Mit pytest und pytest-mock fast unschlagbar.

Sinon.JS (JavaScript)

Stubs, Mocks, Spies, Fakes – alles in einer Library. Funktioniert mit jedem Test-Runner.

Jest Mock (JavaScript)

In Jest eingebaut: jest.fn(), jest.mock(). Sehr beliebt in React-Welt.

Moq (.NET)

Der C#-Standard. Fluent-API ähnlich Mockito.

EasyMock / PowerMock

Ältere Java-Mock-Libs. PowerMock kann statische Methoden mocken (umstritten).

7) Verbindung zu Integrationstests

In L2 hast du die Begriffe Stub und Treiber (Driver) bei Integrations-Strategien kennengelernt:

Stub bei Top-Down-Integration ist ein Stellvertreter unter dem zu testenden Modul – simuliert eine noch nicht fertige Komponente und gibt Standard-Antworten zurück. Genau die gleiche Idee wie hier.
Treiber ist das Gegenstück über dem Modul – simuliert den Aufrufer. Im Unit-Test-Kontext entspricht das dem Test selbst (er ruft die Methode auf).

Stub und Treiber sind also einfach spezielle Test-Doubles aus der Integrationstest-Welt.

8) Anti-Patterns beim Mocking

Mocking-Sünden, die du vermeiden solltest

✗ Über-Mocking

Alles wird gemockt – am Ende testest du nur, dass Mocks aufgerufen werden. Der Test passt zum Test, nicht zum echten System.

✗ Eigene Datentypen mocken

Mock einer eigenen Wert-Klasse (z.B. Geld, Adresse) ist sinnlos. Echte Instanz nutzen.

✗ Mocks ohne Verify

Mocks erstellen, aber nie prüfen, ob sie aufgerufen wurden – dann hätte ein Stub gereicht.

✗ Tests an Mock-Sequenzen koppeln

„Methode A muss vor Methode B aufgerufen werden" – sehr brüchig, refactoring-feindlich.

✗ Static-Mocking überall

Statische Methoden mocken zu müssen ist oft ein Zeichen, dass die Architektur Probleme hat (siehe K49 Dependency Injection).

✗ Mocks für Standard-Bibliotheken

List, Map, String, Datum mocken? Kaum je sinnvoll. Diese sind selbst zuverlässig.

9) Praxis-Faustregel: wann mocken?

Eine gute Heuristik – mocke, wenn die Abhängigkeit ist:

Langsam: Datenbank, Netzwerk, Filesystem.
Unzuverlässig: externe APIs, Drittsysteme.
Teuer: Zahlungs-APIs, SMS-Dienste.
Schwer kontrollierbar: Zeit, Zufall, User-Eingaben.
Mit Nebenwirkungen: echte E-Mails verschicken, Daten löschen.

Mocke nicht, wenn die Abhängigkeit schnell, deterministisch und harmlos ist (Wert-Objekte, Math, String-Utilities).

10) Dependency Injection als Voraussetzung

Damit Mocking überhaupt möglich ist, muss der Code Abhängigkeiten von außen reinbekommen können – nicht selbst erzeugen. Das ist das Prinzip der Dependency Injection (DI), eines der wichtigsten Design-Prinzipien moderner Software (vgl. K49 Entwurfsmuster).

Schlecht testbar: new EmailService() direkt in einer Methode aufrufen. Gut testbar: EmailService als Konstruktor-Parameter erhalten. Im Produktiv-Code wird der echte injiziert, im Test der Mock.

11) Klausur-Highlights

Die 5 Test-Double-Typen nennen und unterscheiden können.
Stub vs. Mock: Stub gibt Antworten, Mock prüft Interaktionen.
Stub und Treiber im Integration-Test-Kontext (L2).
Mockito (Java) und unittest.mock (Python) als Standard-Frameworks.
Wann mocken? Langsame, unzuverlässige, teure Abhängigkeiten.

Zusammenfassung

Test-Doubles ersetzen echte Abhängigkeiten in Unit-Tests. Fünf Typen (Meszaros): Dummy (Platzhalter), Stub (vorgegebene Antworten), Spy (echtes Objekt + Aufrufprotokoll), Mock (Stub + Erwartungsprüfung), Fake (vereinfachte echte Implementation, z.B. In-Memory-DB). Stub = state-based, Mock = interaction-based. Frameworks: Mockito (Java), unittest.mock (Python), Sinon/Jest (JS). Voraussetzung: Dependency Injection. Nächste Lektion: Testplan und Testprotokoll.