Idź do:
Czym jest mockowanie?
Mockowanie to właśnie udawanie, symulowanie odpowiedzi jakiegoś serwisu, aby była zgodna z naszymi oczekiwaniami. Czyli odawanie, że system, który działa, nie działa albo odwrotnie (np. testowanie obsługi błędów). Można też symulować konkretne odpowiedzi, aby sprawdzić, czy zwracane wartości są przez naszą aplikację poprawnie obliczane. W testach jednostkowych, gdzie mamy większe pole do popisu, mockować można obiekty klas, z którymi wchodzimy w interakcję. W testach end-to-end nie schodzimy do tego poziomu, więc na potrzeby tego artykułu zajmiemy się symulacją odpowiedzi z serwisów internetowych. A dlaczego warto stosować tę technikę?
Zalety mockowania
Zalet i zastosowań mockowania jest wiele. Pozwala nam ono m.in.:
- Zasymulować różne wartości odpowiedzi (np. przetestowanie obsługi timeout’ów).
- Zasymulować stałe czasy odpowiedzi do wykrycia zmian w naszej aplikacji przez nieoczekiwaną obsługę danej odpowiedzi.
- Sprawdzić odporność na downtime aplikacji zewnętrznych spowodowany czy to błędem występującym w nowej wersji, awarią czy może tym, że właśnie jest ona instalowana.
W korporacyjnym świecie ASAP-ów mockowanie staje się przydatnym narzędziem do omijania takich przeszkód.
Należy jednak mieć na uwadze, że pracując tylko z mockami, możemy przeoczyć zmiany w mockowanych komponentach. Dlatego warto też sprawdzać pełną integrację end-to-end.
Przykładowy scenariusz
Teoretycznie mockujemy tylko to, co leży poza obszarem naszych działań. Jeśli jednak jakaś część naszego systemu również zawiodła, to warto ją tymczasowo zmockować, aby móc przetestować dalszą funkcjonalność. Wyobraźmy sobie taki scenariusz, w którym nasz system składa się z dwóch komponentów:
- serwer
- klient
Problem
Programiści komponentu serwera dokonują dużych zmian, przez co jest on niestabilny w środowisku testowym. Programiści komponentu klienta pracują nad kluczową dla biznesu zmianą, która ma zostać dostarczona w tym Sprincie. Niestety, każde zapytanie klienta do serwera skutkuje błędem 503 i osiągnięcie celu Sprintu wisi na włosku.
Rozwiązanie
Wiemy, jakich odpowiedzi możemy się spodziewać z serwera (przykładowo, mamy nagrania ze środowiska produkcyjnego lub z poprzedniej, działającej wersji serwera albo posiadamy dokumentację). Możemy więc zasymulować udzielanie przez serwer poprawnej odpowiedzi, co pozwala przetestować nasz komponent i dostarczyć cel Sprintu, wdrażając go w środowisku produkcyjnym (instalowany będzie tylko nasz komponent). Oczywiście warto też sprawdzić pełną integrację (UAT/PREPROD), gdy jest taka możliwość. Dobrą praktyką jest przeprowadzanie testów integracji, aby sprawdzić, czy nasze mocki nie są przestarzałe. Zdarza się, że zostanie zainstalowana jakaś zmiana, o której nie zostaliśmy poinformowani, a testy integracji dają szansę takie zmiany wychwycić.
Dostępne narzędzia
Aplikacji pozwalających na mockowanie API rest jest mnóstwo i na pewno każdy znajdzie coś dla siebie. Ja chciałbym opisać kilka z nich i pokrótce wskazać ich wady i zalety.
- SoapUI – narzędzie w wersji darmowej, w zupełności wystarczy w większości sytuacji do testów rozwijanej aplikacji. Posiada interfejs graficzny i w łatwy sposób można wyklikać interesujące nas mocki, co niestety jest także wadą tego rozwiązania (konieczność klikania).
- Postman – dzieli ten sam zestaw wad i zalet co SoapUI, jednak GUI może dla niektórych okazać się przyjemniejsze w obsłudze. Do tworzenia mocków wymaga jednak założenia darmowego konta.
- MockServer i WireMock – same w sobie nie posiadają GUI, jednak ich możliwości konfiguracji przerastają poprzednio opisane rozwiązania. Można je uruchomić jako proces standalone lub podczas budowania projektu z testami automatycznymi. Oba są darmowe i spełnią większość oczekiwań nawet najbardziej wymagających użytkowników. WireMock charakteryzuje się jednak lepszą skalowalnością.
- mocky.IO i beecepto.com – są to rozwiązania webowe i o ile wyróżniają się łatwością obsługi, o tyle posiadają pewną znaczącą wadę: znajdują się na odległym serwerze i czasy odpowiedzi oraz sama jego dostępność mogą być ograniczone.
Mockowanie w praktyce
Przejdźmy zatem do praktyki. Na przykładzie MockServera i Javy pokażę, jak skonfigurować przykładowy mock bez napisania ani jednej linii kodu, a to przy pomocy Mavena.
Aby skonfigurować Mock Server, wystarczy:
- dodać zależności w pom.xml
- a także plugin, który nasz serwer uruchomi
Możemy z tego wyczytać, że nasz serwer zostanie uruchomiony przez Maven na localhost:1080 w fazie process-test-classes i zatrzymany w fazie verify.
Projekt budujemy za pomocą polecenia:
mvn clean verify -Dmockserver.initializationJsonPath=src/test/resources/REST/mockserver/initialize.json
I tu pojawia się tajemniczy plik .json który zawiera całą konfigurację związaną z mockowanymi endpointami – czyli określenie typów i parametrów żądan, a także odpowiedzi na te żądania.
U mnie jest to przykład dla kursu walut ze strony NBP, przyjmujący za żądanie GET na adresie http://api.nbp.pl/api/exchangerates/tables/A/?format=json i zwracający odpowiedź z kodem 200 – OK, w formacie json, z kursem walutowym dla tajskiego bahta w treści:
Teraz już wystarczy podmienić adres naszego http://api.nbp.pl na http://localhost:1080 i cieszyć się najniższym w historii kursem bahta tajskiego widocznego w naszych testach.
Jak widzicie, konfiguracja nie jest trudna, nie wymaga pisania kodu, a kolejne mocki można dodawać, rozszerzając plik json.
Mockowanie w testach manualnych
Jeśli chcecie natomiast korzystać z dobrodziejstw mockowania w testach manualnych, polecam darmową wersję narzędzia SoapUI. Posiada interfejs graficzny dzięki czemu wyklikanie potrzebnej konfiguracji nie sprawia większych problemów.
Poniżej przykład dla naszego NBP:
Po uruchomieniu aplikacji tworzymy nowy projekt. Klikamy odpowiednio File (1) i New SOAP Project (2)
Następnie nadajemy mu adekwatną nazwę (1) i klikamy OK.
Na naszym nowo utworzonym projekcie klikamy PPM i wybieramy New REST MockService (2)
Nadajemy odpowiednią nazwę (1) i zatwierdzamy, klikając OK.
Tu (1) widzimy, że nasz MockService działa na domyślnym porcie 8080.
Dodajemy do naszego serwisu akcję odpowiadającą żądaniu http. Klikamy PPM w naszym serwisie (1) i wybieramy Add new mock action (2).
W tym miejscu (1) wybieramy metodę GET/POST/PUT i wiele innych. Nas interesuje GET.
Podajemy też ścieżkę do API (2) i zatwierdzamy, klikając OK.
Skoro mamy zdefiniowane żądanie, to czas najwyższy na dodanie odpowiedzi. Klikamy PPM na żądaniu (1) i wybieramy New MockResponse (2).
Odpowiedź też potrzebuje swojej nazwy. Wpisujemy ją (1) i zatwierdzamy, klikając OK.
W naszej odpowiedzi dodajemy nagłówek (1) i wpisujemy Content-Type (2). Nie jest to konieczne, ale najlepiej dodać wszystkie nagłówki, jakie występują w faktycznej odpowiedzi serwera.
Tutaj odpowiedź jest w formacie json, więc uzupełniamy application/json (1). W formatce poniżej (2) wklejamy oczekiwane response body (to ten obiekt json, który normalnie zwraca serwer i którym będzie odpowiadał mock).
Zostało nam już tylko uruchomienie serwera. Klikamy dwukrotnie nasz MockService (1) i Start (2).
Nasz serwer już działa i jeśli wykonamy zapytanie pod adresem http://localhost:8080/api/exchangerates/tables/A/, zobaczymy w logu (3) informację o powodzeniu tej operacji.
Jak widzicie, w SoapUI trzeba się troszeczkę więcej naklikać, ale za to jest to o wiele bardziej przyjazne dla osób, które dopiero stawiają pierwsze kroki w tym obszarze. Dodatkowo uzyskujemy serwer standalone.
Podsumowanie
Mockowanie w testach to temat oczywiście o wiele szerszy. Mam nadzieję, że w tym krótkim artykule udało mi się zachęcić Was do sprawdzenia, jakie możliwości daje. Istnieje wiele darmowych aplikacji, które ułatwią Wam wejście w świat mockowania, a ich obsługa jest zwykle bardzo intuicyjna.
