Mockito — co to jest, kluczowe pojęcia i zasada działania

Co to jest Mockito?

Mockito to biblioteka o otwartym kodzie źródłowym do tworzenia obiektów mock (atrap) w testach jednostkowych w Javie, Kotlinie i innych językach JVM. W przeciwieństwie do JUnit, który odpowiada za uruchamianie testów, Mockito rozwiązuje problem izolacji — zastępuje rzeczywiste zależności testowanej klasy przewidywalnymi obiektami.

Bez mocków testowanie metody, która odwołuje się do bazy danych lub zewnętrznego API, wymaga skonfigurowania rzeczywistego środowiska — wdrożenia bazy danych, uruchomienia serwera. Mockito zastępuje te zależności obiektami o stałym zachowaniu: metoda repository.findById(1) zawsze zwraca określony obiekt User, bez odwoływania się do bazy.

Architektura Mockito opiera się na wzorcu Proxy (dla interfejsów i klas). Biblioteka generuje podklasę lub proxy dla określonego typu i przechwytuje wszystkie wywołania metod, zwracając wartości domyślne lub określone przez when().thenReturn().

Jak działa Mockito

Zasada działania Mockito opiera się na trzech podstawowych operacjach: tworzenie mocka, konfiguracja zachowania (stubbing) i weryfikacja wywołań (verification). Każda operacja wykorzystuje metody statyczne z klasy org.mockito.Mockito — najczęściej ładowanej klasy w ekosystemie Java według statystyk Maven Central. Wszystkie wywołania metod mocka są zapisywane w pamięci, co pozwala później sprawdzić je przez verify.

Trzy kroki testu z Mockito

Typowy test z Mockito składa się z trzech faz: Arrange — tworzenie mocków i konfiguracja stubów przez when().thenReturn(), Act — wywołanie testowanej metody, Assert — sprawdzenie wyniku przez assertEquals i verify(mock). Takie podejście nazywa się AAA (Arrange-Act-Assert).

Podstawowy przykład z mockiem repozytorium

Rozważmy prosty test, w którym Mockito zastępuje repozytorium użytkowników. Metoda when().thenReturn() konfiguruje mocka tak, aby wywołanie findById zwracało wcześniej przygotowany obiekt User.

// Tworzymy mock repozytorium
UserRepository mockRepo = mock(UserRepository.class);

// Konfigurujemy zachowanie: przy findById(1) zwróć użytkownika
when(mockRepo.findById(1)).thenReturn(new User("Alice"));

// Sprawdzamy, czy metoda rzeczywiście została wywołana
User result = mockRepo.findById(1);
assertEquals("Alice", result.getName());
verify(mockRepo).findById(1);

Tworzenie obiektów mock

Mockito udostępnia dwa sposoby tworzenia mocków: statyczną metodę mock(Class) oraz adnotację @Mock z inicjalizacją przez MockitoAnnotations.openMocks(). Pierwszy sposób jest zwięzły dla jednego-dwóch mocków, drugi jest wygodny, gdy zależności jest wiele — adnotacje redukują kod boilerplate.

Przez statyczną metodę mock()

Metoda mock() przyjmuje klasę i zwraca obiekt-atrapę, który można skonfigurować przez when().thenReturn(). Wszystkie nieskonfigurowane metody zwracają wartości domyślne: 0 dla liczb, false dla boolean, null dla obiektów.

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

Przez adnotację @Mock z JUnit 5

Adnotacja @Mock w połączeniu z @ExtendWith(MockitoExtension.class) automatycznie tworzy mocki dla wszystkich pól klasy testowej. Rozszerzenie MockitoExtension odpowiada za inicjalizację przed każdym testem.

@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: konfiguracja zachowania mocka

Stubbing to proces określania, co metoda mocka powinna zwrócić przy wywołaniu z określonymi argumentami. Podstawowa składnia: when(mock.method(args)).thenReturn(value). Dla różnych scenariuszy Mockito oferuje kilka wariantów metod then.

Dynamiczna odpowiedź przez thenAnswer

Gdy zwracana wartość zależy od argumentów wywołania, używamy thenAnswer z lambdą. Jest to przydatne do imitowania pracy z rzeczywistymi danymi — na przykład generowania ID na podstawie przekazanego obiektu.

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

Verify: sprawdzanie interakcji z mockiem

Verify to unikalna możliwość Mockito, której nie oferują starsze biblioteki obiektów mock (EasyMock, jMock).

Verify sprawia, że testy są bardziej niezawodne, ponieważ sprawdza nie tylko zwracaną wartość, ale także efekty uboczne — wywołania metod, które nie zwracają wyniku (metody void). Metoda verify(mock).methodName(args) sprawdza, czy określona metoda mocka została wywołana z podanymi argumentami. Pozwala to testować nie tylko wynik, ale także proces — fakt odwołania do zależności.

Sprawdzanie liczby wywołań

Domyślnie verify sprawdza, że metoda została wywołana dokładnie raz. Jeśli potrzebna jest inna liczba — używamy times(n), atLeast(n), never() i innych modyfikatorów z klasy Mockito.

// Sprawdzanie liczby wywołań
verify(repository, times(3)).save(any());
verify(repository, never()).delete(any());
verify(repository, atLeastOnce()).findById(1);

// Sprawdzanie kolejności wywołań
InOrder inOrder = inOrder(repository);
inOrder.verify(repository).save(any());
inOrder.verify(repository).flush();

ArgumentCaptor do przechwytywania argumentów

Gdy trzeba sprawdzić, z jakim dokładnie obiektem została wywołana metoda, używamy ArgumentCaptor. Przechwytuje on wartość argumentu podczas wywołania i pozwala sprawdzić jego pola osobno. ArgumentCaptor jest szczególnie przydatny, gdy testowany kod tworzy obiekt wewnętrznie i przekazuje go do zależności — nie można tego obiektu sprawdzić w inny sposób.

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

Adnotacje @Mock i @InjectMocks

@Mock i @InjectMocks to dwie kluczowe adnotacje Mockito, które znacznie redukują kod boilerplate. @Mock tworzy mocka dla pola, a @InjectMocks wstrzykuje wszystkie mocki z klasy testowej do testowanego obiektu przez konstruktor, setter lub pole.

Mechanizm @InjectMocks próbuje wstrzyknąć zależności w następującej kolejności: konstruktor z największą liczbą argumentów, setter według typu, pole prywatne. Jeśli żaden sposób nie zadziała — obiekt pozostaje z null-owymi zależnościami, a test zakończy się NullPointerException.

Zasady używania @InjectMocks

Ważne jest zrozumienie: @InjectMocks nie analizuje typów pól — podstawia każdy mock zgodny typem. Jeśli w klasie są dwa pola tego samego typu — Mockito może wstrzyknąć niewłaściwy mock. W takich przypadkach zaleca się użycie jawnego konstruktora z przekazaniem mocków.

Mockito w projektach Android

W rozwoju aplikacji Android Mockito jest używany razem z JUnit do testowania ViewModel, Repository i UseCase. Ponieważ te klasy działają na JVM bez kontekstu Androida, Mockito zastępuje ich zależności — Room DAO, Retrofit API, SharedPreferences — stubami o przewidywalnym zachowaniu.

Konfiguracja Gradle dla Mockito

Aby dodać Mockito do projektu Android, wystarczy dodać zależność mockito-core lub mockito-inline (ta druga obsługuje mockowanie klas finalnych i metod statycznych). Wersja 5.12.0 (2024) zawiera obsługę Java 21 i ulepszoną integrację z JUnit 5.

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

Mockito i PowerMock: przestarzała praktyka

Wcześniej do mockowania metod statycznych i konstruktorów wymagany był PowerMock — rozszerzenie działające przez instrumentację bajtkodu. Od Mockito 5.x z mockito-inline ta funkcjonalność jest wbudowana bezpośrednio: mockStatic(ClassName.class) pozwala mockować metody statyczne bez dodatkowych bibliotek.

Testowanie ViewModel z Mockito

Typowy scenariusz: ViewModel wywołuje metodę repozytorium i przekształca wynik w stan UI. Mockito zastępuje repozytorium, a test sprawdza, czy ViewModel poprawnie obsługuje odpowiedź sukcesu i błąd. Przy zastosowaniu architektury Clean Architecture mocki są tworzone dla każdej warstwy: DataSource, Repository i UseCase — pozwala to testować każdą warstwę w izolacji.

• success case — when(repo.getData()).thenReturn(Result.success(data)) → sprawdzamy state = Success(data).
• error case — when(repo.getData()).thenReturn(Result.error(exception)) → sprawdzamy state = Error(message).
• loading state — verify, że ViewModel ustawiła isLoading = true przed wywołaniem repozytorium.