Mockito — was es ist, Schlüsselkonzepte und Funktionsprinzip

Was ist Mockito?

Mockito ist eine Open-Source-Bibliothek zum Erstellen von Mock-Objekten (Stubs) in Komponententests für Java, Kotlin und andere JVM-Sprachen. Im Gegensatz zu JUnit, das für die Testausführung zuständig ist, löst Mockito das Problem der Isolation — es ersetzt die echten Abhängigkeiten der getesteten Klasse durch vorhersagbare Objekte.

Ohne Mocks erfordert das Testen einer Methode, die auf eine Datenbank oder externe API zugreift, die Einrichtung einer realen Umgebung — Bereitstellen einer Datenbank, Starten eines Servers. Mockito ersetzt diese Abhängigkeiten durch Objekte mit festgelegtem Verhalten: Die Methode repository.findById(1) gibt immer ein bestimmtes User-Objekt zurück, ohne auf die Datenbank zuzugreifen.

Die Architektur von Mockito basiert auf dem Proxy-Muster (für Schnittstellen und Klassen). Die Bibliothek generiert eine Unterklasse oder einen Proxy für den angegebenen Typ und fängt alle Methodenaufrufe ab, wobei sie Standardwerte oder über when().thenReturn() festgelegte Werte zurückgibt.

Wie Mockito funktioniert

Das Prinzip der Funktionsweise von Mockito basiert auf drei grundlegenden Operationen: Erstellen des Mocks, Konfigurieren des Verhaltens (Stubbing) und Überprüfen von Aufrufen (Verification). Jede Operation verwendet statische Methoden aus der Klasse org.mockito.Mockito — der am häufigsten heruntergeladenen Klasse im Java-Ökosystem laut Maven-Central-Statistiken. Alle Methodenaufrufe des Mocks werden im Speicher aufgezeichnet, was eine spätere Überprüfung durch verify ermöglicht.

Drei Schritte eines Tests mit Mockito

Ein typischer Test mit Mockito besteht aus drei Phasen: Arrange — Erstellen von Mocks und Konfigurieren von Stubs über when().thenReturn(), Act — Aufruf der getesteten Methode, Assert — Überprüfung des Ergebnisses über assertEquals und verify(mock). Dieser Ansatz wird AAA (Arrange-Act-Assert) genannt.

Basisbeispiel mit einem Repository-Mock

Betrachten wir einen einfachen Test, bei dem Mockito ein Benutzer-Repository ersetzt. Die Methode when().thenReturn() konfiguriert den Mock so, dass der findById-Aufruf ein vorbereitetes User-Objekt zurückgibt.

// Repository-Mock erstellen
UserRepository mockRepo = mock(UserRepository.class);

// Verhalten konfigurieren: findById(1) gibt einen Benutzer zurück
when(mockRepo.findById(1)).thenReturn(new User("Alice"));

// Überprüfen, dass die Methode tatsächlich aufgerufen wurde
User result = mockRepo.findById(1);
assertEquals("Alice", result.getName());
verify(mockRepo).findById(1);

Erstellung von Mock-Objekten

Mockito bietet zwei Möglichkeiten zum Erstellen von Mocks: die statische Methode mock(Class) und die Annotation @Mock mit Initialisierung über MockitoAnnotations.openMocks(). Der erste Ansatz ist kompakt für ein oder zwei Mocks, der zweite ist praktisch, wenn viele Abhängigkeiten bestehen — Annotationen reduzieren den Boilerplate-Code.

Über die statische Methode mock()

Die Methode mock() nimmt eine Klasse entgegen und gibt ein Stub-Objekt zurück, das über when().thenReturn() konfiguriert werden kann. Alle nicht konfigurierten Methoden geben Standardwerte zurück: 0 für Zahlen, false für boolean, null für Objekte.

ApiClient apiClient = mock(ApiClient.class);
Database database = mock(Database.class);

Über die @Mock-Annotation mit JUnit 5

Die Annotation @Mock in Kombination mit @ExtendWith(MockitoExtension.class) erstellt automatisch Mocks für alle Felder der Testklasse. Die MockitoExtension ist für die Initialisierung vor jedem Test verantwortlich.

@ExtendWith(MockitoExtension.class)
class UserServiceTest {

    @Mock
    private UserRepository userRepository;

    @InjectMocks
    private UserService userService;

    @Test
    void getUserShouldReturnUserFromRepo() {
        when(userRepository.findById(1)).thenReturn(new User("Alice"));
        User result = userService.getUser(1);
        assertEquals("Alice", result.getName());
    }
}

Stubbing: Konfiguration des Mock-Verhaltens

Stubbing ist der Prozess der Definition, was eine Mock-Methode zurückgeben soll, wenn sie mit bestimmten Argumenten aufgerufen wird. Die grundlegende Syntax: when(mock.method(args)).thenReturn(value). Für verschiedene Szenarien bietet Mockito mehrere Varianten von then-Methoden.

Dynamische Antwort über thenAnswer

Wenn der Rückgabewert von den Aufrufargumenten abhängt, wird thenAnswer mit einem Lambda verwendet. Dies ist nützlich, um die Arbeit mit echten Daten zu simulieren — beispielsweise das Generieren einer ID basierend auf dem übergebenen Objekt.

when(repository.save(any())).thenAnswer(invocation -> {
    User user = invocation.getArgument(0);
    user.setId(42);
    return user;
});

Verify: Prüfung der Interaktionen mit dem Mock

Verify ist eine einzigartige Funktion von Mockito, die ältere Mock-Objekt-Bibliotheken (EasyMock, jMock) nicht bieten.

Verify macht Tests zuverlässiger, weil es nicht nur den Rückgabewert, sondern auch Seiteneffekte — Aufrufe von Methoden, die kein Ergebnis zurückgeben (void-Methoden) — überprüft. Die Methode verify(mock).methodName(args) prüft, ob eine bestimmte Mock-Methode mit den angegebenen Argumenten aufgerufen wurde. Dies ermöglicht es, nicht nur das Ergebnis, sondern auch den Prozess zu testen — die Tatsache des Zugriffs auf die Abhängigkeit.

Überprüfung der Anzahl der Aufrufe

Standardmäßig prüft verify, dass die Methode genau einmal aufgerufen wurde. Wenn eine andere Anzahl benötigt wird, werden times(n), atLeast(n), never() und andere Modifikatoren aus der Klasse Mockito verwendet.

// Überprüfung der Anzahl der Aufrufe
verify(repository, times(3)).save(any());
verify(repository, never()).delete(any());
verify(repository, atLeastOnce()).findById(1);

// Überprüfung der Reihenfolge der Aufrufe
InOrder inOrder = inOrder(repository);
inOrder.verify(repository).save(any());
inOrder.verify(repository).flush();

ArgumentCaptor zum Erfassen von Argumenten

Wenn Sie überprüfen müssen, mit welchem genauen Objekt eine Methode aufgerufen wurde, wird ArgumentCaptor verwendet. Es erfasst den Argumentwert während des Aufrufs und ermöglicht die überprüfung seiner Felder einzeln. ArgumentCaptor ist besonders nützlich, wenn der getestete Code intern ein Objekt erstellt und es an eine Abhängigkeit übergibt — Sie können dieses Objekt sonst nicht überprüfen.

ArgumentCaptor<User> captor = ArgumentCaptor.forClass(User.class);
verify(repository).save(captor.capture());
assertEquals("Alice", captor.getValue().getName());

Annotationen @Mock und @InjectMocks

@Mock und @InjectMocks sind zwei wichtige Mockito-Annotationen, die Boilerplate-Code erheblich reduzieren. @Mock erstellt einen Mock für ein Feld, und @InjectMocks injiziert alle Mocks aus der Testklasse in das getestete Objekt über Konstruktor, Setter oder Feld.

Der Mechanismus von @InjectMocks versucht, Abhängigkeiten in der folgenden Reihenfolge zu injizieren: Konstruktor mit den meisten Argumenten, Setter nach Typ, privates Feld. Wenn keine dieser Methoden funktioniert, bleibt das Objekt mit null-Abhängigkeiten zurück, und der Test schlägt mit einer NullPointerException fehl.

Regeln für die Verwendung von @InjectMocks

Es ist wichtig zu verstehen: @InjectMocks analysiert keine Feldtypen — es ersetzt jeden Mock, der vom Typ her kompatibel ist. Wenn eine Klasse zwei Felder desselben Typs hat, kann Mockito den falschen Mock injizieren. In solchen Fällen wird empfohlen, einen expliziten Konstruktor mit Mock-Parametern zu verwenden.

Mockito in Android-Projekten

In der Android-Entwicklung wird Mockito zusammen mit JUnit zum Testen von ViewModel, Repository und UseCase verwendet. Da diese Klassen auf der JVM ohne Android-Kontext ausgeführt werden, ersetzt Mockito ihre Abhängigkeiten — Room DAO, Retrofit API, SharedPreferences — durch Stubs mit vorhersagbarem Verhalten.

Gradle-Setup für Mockito

Um Mockito zu einem Android-Projekt hinzuzufügen, fügen Sie einfach die Abhängigkeit mockito-core oder mockito-inline hinzu (letztere unterstützt das Mocken von finalen Klassen und statischen Methoden). Version 5.12.0 (2024) enthält Java-21-Unterstützung und eine verbesserte JUnit-5-Integration.

// build.gradle.kts (module)
dependencies {
    testImplementation("org.mockito:mockito-core:5.12.0")
    testImplementation("org.mockito:mockito-junit-jupiter:5.12.0")
}

Mockito und PowerMock: veraltete Praxis

Früher war für das Mocken von statischen Methoden und Konstruktoren PowerMock erforderlich — eine Erweiterung, die durch Bytecode-Instrumentierung funktionierte. Ab Mockito 5.x mit mockito-inline ist diese Fähigkeit direkt integriert: mockStatic(ClassName.class) ermöglicht das Mocken von statischen Methoden ohne zusätzliche Bibliotheken.

Testen von ViewModel mit Mockito

Ein typisches Szenario: Ein ViewModel ruft eine Repository-Methode auf und transformiert das Ergebnis in einen UI-Zustand. Mockito ersetzt das Repository, und der Test überprüft, ob das ViewModel sowohl die erfolgreiche Antwort als auch den Fehler korrekt behandelt. Bei Verwendung der Clean Architecture werden Mocks für jede Schicht erstellt: DataSource, Repository und UseCase — dies ermöglicht es, jede Schicht isoliert zu testen.

• Erfolgsfall — when(repo.getData()).thenReturn(Result.success(data)) → state = Success(data) überprüfen.
• Fehlerfall — when(repo.getData()).thenReturn(Result.error(exception)) → state = Error(message) überprüfen.
• Ladezustand — verify, dass das ViewModel isLoading = true gesetzt hat, bevor es das Repository aufgerufen hat.