Moq – co to jest i jak działa w programowaniu?

Moq to popularny framework do tworzenia mocków w środowisku .NET, który umożliwia izolowanie testowanych komponentów przy użyciu techniki „mockowania” zależności. Działa poprzez dynamiczne generowanie obiektów udających rzeczywiste zależności, co pozwala na precyzyjne definiowanie ich zachowań w testach jednostkowych. W dalszej części artykułu wyjaśnimy dokładnie, jak używać tego narzędzia i dlaczego warto je włączyć do codziennego warsztatu programisty.

Czym jest Moq i jakie problemy rozwiązuje?

Moq to lekka, otwarta biblioteka do mockowania dla platformy .NET, napisana z wykorzystaniem wyrażeń lambda i interfejsów generycznych. Jej głównym zadaniem jest eliminacja zewnętrznych zależności z testów jednostkowych, takich jak bazy danych, usługi sieciowe czy systemy plików. Zamiast uruchamiać prawdziwe połączenie z serwerem SQL, programista tworzy mock implementujący ten sam interfejs i symulujący odpowiedź bazy.

Podstawowym założeniem jest skupienie testu wyłącznie na logice metody badanej. Oddzielenie od zależności sprawia, że testy są szybsze, powtarzalne i odporne na awarie infrastruktury. Co więcej, biblioteka pozwala na konfigurację rzucanych wyjątków, śledzenie wywołań i weryfikację, czy określona metoda została zawołana z oczekiwanymi parametrami.

Jak działa podstawowy mechanizm generowania mocków?

Sercem Moqa jest klasa generyczna Mock, która po instancji tworzy obiekt udający zależność. Wywołanie var mock = new Mock<IService>(); buduje w locie typ zastępujący prawdziwą implementację, a właściwość mock.Object udostępnia gotowy do wstrzyknięcia obiekt. Za kulisami framework wykorzystuje techniki refleksji oraz proxy biblioteki Castle Core do dynamicznego generowania kodu.

Gdy testowana metoda odwołuje się do członków takiego mocka, a wcześniej nie zdefiniowaliśmy oczekiwanego zachowania, domyślna implementacja zwraca wartości domyślne dla typów (null dla referencyjnych, 0 dla liczbowych). Dopiero użycie metody Setup pozwala na nadpisanie tych odpowiedzi.

Konfiguracja zachowań za pomocą Setup

Metoda Setup przyjmuje wyrażenie lambda wskazujące na konkretny członek interfejsu i zwraca obiekt ISetup, na którym łańcuchowo wywołujemy Returns. Na przykład: mock.Setup(x => x.GetData()).Returns(new List<string> { "test" }); sprawia, że każde wywołanie GetData zwróci listę z jednym elementem. Parametry używamy, dopisując je do lambdy – Setup(x => x.GetById(It.IsAny<int>())) umożliwia dopasowanie dowolnego argumentu.

Do ograniczania dopasowań służą statyczne metody klasy It: It.Is z predykatem, It.IsInRange czy It.IsRegex. Dzięki nim mock potrafi różnicować odpowiedzi w zależności od wartości przekazanych do metody, co jest przydatne przy testowaniu gałęzi warunkowych.

W przypadku metod zwracających typy referencyjne można również łańcuchować konfiguracje z użyciem CallBase – jeśli mock tworzymy jako Mock(Loose) lub Mock(Strict), opcja ta decyduje o domyślnej reakcji na nieskonfigurowane wywołania. Domyślnie Moq działa w trybie luźnym, nie rzucając wyjątków, co upraszcza kod.

Właściwość Object mocka jest leniwie inicjalizowana – rzeczywiste proxy tworzone jest dopiero przy pierwszym odwołaniu.

Weryfikacja wywołań – upewnij się, że interakcje zaszły

Po wykonaniu testu kluczowe jest sprawdzenie, czy zależności zostały użyte w oczekiwany sposób. Metoda Verify na obiekcie mocka sprawdza, czy dana metoda była wywoływana co najmniej raz. Przykład: mock.Verify(x => x.Save(It.IsAny<string>()), Times.Once); potwierdza, że Save zawołano dokładnie jeden raz. Klasa Times udostępnia opcje takie jak Times.AtLeast(n), Times.AtMost(n), Times.Never czy Times.Exactly(n).

Weryfikacji można również poddać propercje – zarówno gettery, jak i settery. Jeśli zależy nam na śledzeniu zmian mockowanego obiektu, korzystamy z mock.VerifySet(x => x.Name = "Jan"). Oprócz tego Moq umożliwia sprawdzanie kolejności wywołań poprzez porównywanie wygenerowanych znaczników czasowych, aczkolwiek nie jest to wbudowana funkcja i wymaga pomocniczych struktur.

Callback – gdy potrzebna jest logika pośrednia

Metoda Callback pozwala wstrzyknąć własną akcję wykonywaną w momencie wywołania mockowanego członka. Przydaje się, gdy trzeba zmodyfikować zewnętrzną zmienną, zasymulować zapis do kolekcji lub potwierdzić stan przed zwróceniem wyniku. Przykład: mock.Setup(x => x.Add(It.IsAny<int>())).Callback<int>(x => lista.Add(x)); zapisuje każdy dodany element do listy lokalnej, a następnie można zweryfikować jej zawartość.

Callback często łączy się z Returns – można zdefiniować obydwa w jednym łańcuchu, na przykład mock.Setup(...).Callback(...).Returns(...). Należy zachować ostrożność przy asynchronicznych metodach – wtedy lepiej użyć ReturnsAsync, która naturalnie opakowuje wynik w Task.

Zarządzanie kontekstem mocka i jego cyklem życia

Każdy obiekt Mock implementuje interfejs IDisposable, jednak w praktyce rzadko wywołuje się Dispose bezpośrednio – framework xUnit czy NUnit i tak czyści pamięć. Mimo to w przypadku tworzenia wielu mocków w jednym teście warto pamiętać, że każdy z nich utrzymuje wewnętrzny stan zapisanych reguł, a nieostrożne nadpisywanie Setupów może prowadzić do nieoczekiwanych wyników.

Aby bezpiecznie rozdzielić konfigurację, używa się metody Reset lub jeszcze lepiej – tworzy się nowe instancje dla każdego testu. W testach parametryzowanych, gdzie jeden mock jest współdzielony, ostrożnie planujemy sekwencję kolejnych wywołań za pomocą SetupSequence. Wtedy każdy kolejny zwrot może być inny: mock.SetupSequence(x => x.Read()).Returns("pierwszy").Returns("drugi");.

Testowanie kodu asynchronicznego

Dla metod zwracających Task lub Task<T> zamiast zwykłego Returns stosuje się ReturnsAsync, która automatycznie opakowuje wartość w ukończony Task. Dzięki temu await w testowanej metodzie nie rzuca wyjątku. Jeśli jednak chcemy zasymulować opóźnienie, można skorzystać z ThrowsAsync lub połączenia Returns z Task.Delay wewnątrz Callback.

Dobre wsparcie dla asynchroniczności to jeden z powodów, dla których Moq jest często wybierany w nowoczesnych projektach korzystających z async/await. Alternatywnie, przy bardzo rozbudowanych drzewach zależności, zespół może rozważyć wykorzystanie AutoFixture razem z Moq, by zautomatyzować tworzenie złożonych obiektów.

Praktyczne pułapki i ograniczenia Moq

Pierwszą regułą jest, że mockować można tylko metody wirtualne, członki interfejsów oraz klasy abstrakcyjne. Próba skonfigurowania zwykłej metody nie-wirtualnej zakończy się błędem kompilacji lub wyjątkiem w runtime. Dlatego architektura kodu powinna opierać się na kontraktach – wstrzykiwanie zależności przez interfejsy to podstawa testowalności.

Kolejnym problemem bywa nadużywanie mocków. Gdy test wymaga przygotowania dziesiątek sztucznych obiektów, znak to, że klasa jest zbyt silnie sprzężona i warto ją przeprojektować. Moq ma też ograniczenia w mockowaniu metod statycznych czy zapieczętowanych klas – w takich przypadkach trzeba sięgnąć po frameworki izolujące, jak Microsoft Fakes, lub wzorce projektowe (adapter, proxy).

Wersja 4.20 Moqa wprowadziła krytykowaną zależność od sponsorowanego narzędzia – twórcy szybko wycofali się z tego rozwiązania, ale warto śledzić wersję biblioteki w swoich projektach. Bezpieczniej jest pozostać przy stabilnej wersji 4.18 lub nowszej 4.21, korzystając z NuGet Manager i blokując automatyczne aktualizacje, dopóki nie przetestujemy kompatybilności.

Zawsze sprawdzaj licencję i źródło pakietu – Moq korzysta z licencji BSD 3-Clause, co pozwala na używanie go w zamkniętych projektach komercyjnych.

Przykładowe zastosowania w codziennym procesie testowania

W typowej architekturze opartej na CQRS mockuje się repozytoria, serwisy zdarzeń i pośredników. Warunkiem sukcesu jest maksymalne spłaszczenie zależności – jeden mock na jeden test. Częstym błędem jest mockowanie warstwy dostępu do danych bez sprawdzenia poprawności logiki – test wtedy przechodzi, ale nie weryfikuje nic istotnego.

Moq świetnie współpracuje z frameworkami testowymi xUnit i NUnit, a także z biblioteką FluentAssertions, która dodatkowo upiększa czytelność asercji. Zintegrowanie z DI (dependency injection) polega na tym, że w teście rejestrujemy mocka zamiast prawdziwego serwisu – kontener automatycznie go wstrzyknie.

Dla zaawansowanych scenariuszy, gdy zachodzi potrzeba śledzenia stanu obiektów, można skorzystać z kombinacji Callback, zapisującej parametry do lokalnych zmiennych, które następnie badamy z użyciem standardowych asercji. Należy jednak pamiętać, że takie testy szybko tracą czytelność – lepszą praktyką jest zamknięcie logiki weryfikacyjnej w dedykowanej klasie asertora.

Alternatywy dla Moq i podsumowanie wyboru

Rynek .NET oferuje kilka sprawdzonych bibliotek do mockowania – NSubstitute z intuicyjną składnią, FakeItEasy z jawnym tworzeniem fake’ów czy JustMock firmy Telerik wspierający mockowanie statyczne. Każda z nich ma swoje mocne strony: NSubstitute nie wymaga osobnego obiektu Mock, a konfiguracja wygląda bardziej deklaratywnie, FakeItEasy ułatwia mockowanie klas nieabstrakcyjnych z pomocą A.CallTo.

Wybór pomiędzy nimi jest kwestią gustu oraz istniejącej bazy kodu w organizacji. Moq pozostaje liderem pod względem popularności, obszerności dokumentacji i wsparcia społeczności – pytania na StackOverflow gwarantują szybką odpowiedź. Mimo to, jeśli projekt stale zmaga się z mockowaniem klas zapieczętowanych, warto rozważyć przejście na JustMock, przy jednoczesnym startowym koszcie licencyjnym.

W kontekście wydajności różnice są niezauważalne – czas generowania proxy zamyka się w mikrosekundach. Trzeba natomiast rozsądnie podchodzić do tworzenia zbyt wielu mocków – setki obiektów w teście integracyjnym zwolnią wykonanie, ale nie z powodu biblioteki, a ze względu na sam kod inicjalizacyjny.