Menu

Wiremock Tutorial: Wprowadzenie do Wiremock

wiremock tutorial introduction wiremock

Wypróbuj Nasz Instrument Do Eliminowania Problemów

Ten wprowadzający samouczek wideo objaśni funkcje Wiremock i jak uruchomić Wiremock jako samodzielny serwer i jako część testów JUnit:

W tym samouczku omówimy podstawowe pojęcia i szczegóły dotyczące narzędzia Wiremock. Może być używany jako samodzielny serwer HTTP, a także w ramach testów JUnit zgodnie z wymaganiami.

Jest to często używane narzędzie, ponieważ jest open source i ma świetną społeczność współtwórców. Należy do kategorii narzędzi do wirtualizacji usług.

Wprowadzenie do narzędzia Wiremock

Czego się nauczysz:

Co to jest Wiremock?

Mówiąc najprościej, Wiremock to fałszywa konfiguracja do testów integracyjnych. Jest to po prostu serwer pozorowany, który jest wysoce konfigurowalny, aby zwrócić oczekiwaną odpowiedź na dane żądanie.

Jest szeroko stosowany podczas programowania, a co ważniejsze podczas testowania integracji, gdy system lub usługa komunikuje się z jedną lub wieloma zewnętrznymi lub wewnętrznymi zależnościami / usługami.

Spróbujmy ogólnie zrozumieć więcej na temat testowania integracji i dowiedzmy się, jak Wiremock może pomóc pokonać te wyzwania i ułatwić nam życie.

Generalnie, kiedy pojawia się słowo integracja, uderza nas koniec-koniec integracji między dwoma komunikującymi się systemami. Teraz spójrzmy na to z perspektywy testowanej aplikacji, która korzysta z zewnętrznej usługi do wykonania zadania.

Na przykład, załóżmy, że tworzymy aplikację do obsługi podróży lub systemu biletowego online i mamy moduł do sprawdzania statusu PNR, który trafia do zewnętrznego interfejsu API udostępnionego przez Indian Railways.

Teraz, jak możemy przetestować integrację naszej aplikacji z zewnętrznymi interfejsami API?

Można to zrobić na dwa sposoby:

  • Pierwszy, to podejście do testów jednostkowych, w ramach którego blokujemy udostępniony (lub utworzony we własnym zakresie) interfejs, aby nasz system przetestował / zweryfikował skróconą lub fałszywą odpowiedź nawet przed uderzeniem w zewnętrzny interfejs API. To nic innego jak test jednostkowy próbujący wyszydzać zależność zewnętrzną.
  • druga testuje w jakimś środowisku testowym (lub rzeczywistym środowisku produkcyjnym) zależności zewnętrznych. Istnieje jednak kilka wyzwań związanych z tym podejściem, o których mowa poniżej:
    • Zewnętrzne systemy API mogą nie zawsze być dostępne. tj. jesteśmy w dużym stopniu zależni lub zależni od systemów zewnętrznych, a wszelkie przestoje będą miały wpływ na nasze testy, a pośrednio na proces tworzenia / wydawania.
    • Po drugie, zewnętrzne interfejsy API mogą mieć środowisko testowe lub nie. Na przykład, API sprawdzania statusu PNR może zawsze wymagać prawdziwych numerów PNR w celu pobrania i zwrócenia odpowiedzi.
    • W wielu przypadkach trafienie do API wiąże się z kosztami. Na przykład, przypuśćmy, że API kontroli PNR pobiera 100 Rs za każde 1000 żądań. Ponieważ testy integracyjne są zwykle uruchamiane podczas każdej regresji (i przez większość czasu przy każdym zatwierdzeniu), trafienie takiego interfejsu API, które kosztuje nas nawet w celach testowych, może nie być opłacalnym rozwiązaniem.
    • Nie można skonfigurować zewnętrznego interfejsu API, aby zwracał żądaną odpowiedź. Nawet jeśli to możliwe, będziesz musiał utworzyć wiele danych testowych, aby zapewnić różne odpowiedzi dla różnych danych wejściowych żądań.
      Na przykład, chcesz przetestować scenariusze błędów, takie jak interfejs API zwraca różne kody stanu dla różnych typów danych. Ponieważ odpowiedź nie jest pod naszą kontrolą, będziemy musieli utworzyć wiele zestawów danych, aby zweryfikować różne możliwe scenariusze lub wyniki.

Zrozummy te pojęcia za pomocą poniższego diagramu.

Tutaj porównujemy oba podejścia do testowania integracyjnego, tj. Bez serwera próbnego z wykorzystaniem rzeczywistej implementacji zewnętrznej zależności oraz z wykorzystaniem serwera pozorowanego (Wiremock), który makuje odpowiedzi na żądania otrzymane dla zależności.

W tym drugim przypadku znacznie zmniejsza zależność i zależność od rzeczywistej implementacji zależności i daje wiele możliwości konfiguracyjnych bez uszczerbku dla jakości i harmonogramów dostaw.

Wiremock Concepts

Jak Wiremock reaguje na podane żądanie?

Jak wiemy, Wiremock jest programowym serwerem Mock, sposób, w jaki odpowiada na dane żądanie, polega na przechowywaniu wszystkich odpowiednich mapowań (lub fałszywych odpowiedzi) w folderze o nazwie „mapowania”

W Wiremocku znajduje się element dopasowujący, który dopasowuje przychodzące żądania do przechowywanych mapowań i jeśli zwrócone zostanie pomyślne dopasowanie, to pierwsze takie dopasowanie jest zwracane jako odpowiedź na dane żądanie.

Jeśli używasz samodzielnej wersji Wiremock, po uruchomieniu serwera Wiremock zobaczysz folder mappings, który zostanie utworzony w katalogu Wiremock install / jar.

Samouczek wideo: Wprowadzenie do narzędzia Wiremock

darmowa aplikacja do planowania postów na Instagramie

Jak korzystać z Wiremocka?

Zobaczmy teraz, jak możemy użyć tego narzędzia w naszych testach integracji.

Można go używać na następujące sposoby.

Samodzielny serwer Wiremock

Jako samodzielny serwer możesz po prostu utworzyć prostą aplikację Java z zależnością Maven / Gradle dla Wiremock i zachować ją jako działający proces.

Jest to dobra alternatywa, gdy chcesz hostować swój samodzielny serwer na jakimś komputerze i używać go jako pojedynczego serwera do próbowania dla całego projektu lub zespołu. W trybie autonomicznym to narzędzie można również uruchomić, pobierając dostępny samodzielny plik jar tutaj i po prostu uruchom słoik.

Na przykład, załóżmy, że chcesz wdrożyć samodzielną instancję Wiremock na jakimś serwerze w chmurze lub na serwerze lokalnym, możesz po prostu uruchomić ten jar i użyć adresu IP systemu, aby używać go jako usługi hostowanej.

Zobaczmy trochę kroki, aby uruchomić to w trybie autonomicznym (i skonfigurować różne rzeczy, takie jak porty, mapowanie folderów itp.)

# 1) Uruchom jar Wiremock z terminala (lub wiersza poleceń dla użytkowników Windows) jak każdy inny plik JAR (z katalogu instalacyjnego jar Wiremock).

java -jar wiremock-standalone-2.25.1.jar

#dwa) Domyślnie Wiremock działa na localhost: 8080 (jeśli port jest wolny do użytku, powyższe polecenie uruchomi serwer Wiremock w trybie autonomicznym) i zobaczysz dane wyjściowe jak poniżej.

Wiremock działa na hoście lokalnym

# 3) Teraz po uruchomieniu serwera możesz odwiedzić dowolny adres URL na serwerze lokalnym: 8080

Na przykład, http: // localhost: 8080 / get / user / 1 - Ponieważ obecnie nie są ustawiane żadne makiety, otrzymasz odpowiedź, jak pokazano poniżej.

Odpowiedź Wiremock

# 4) Teraz spróbujmy skonfigurować prosty kod pośredniczący / próbny dla tego adresu URL i spróbuj ponownie nacisnąć adres URL. Następnie sprawdzimy, czy naciśnięcie tego samego adresu URL zwraca teraz fałszywą lub skróconą odpowiedź.

curl -X POST --data '{ 'request': { 'url': '/get/user/1', 'method': 'GET' }, 'response': { 'status': 200, 'body': 'Here it is! ' }}' http://localhost:8080/__admin/mappings/new

Spróbujmy najpierw zrozumieć to żądanie CURL:

  • Wysyłamy żądanie CURL POST do http: // localhost: 8080 / __ admin / mappings / new - Teraz jest to lokalizacja, w której będą przechowywane wszystkie mapowania dla serwera Wiremock, który wykonaliśmy / uruchomiliśmy za pomocą pliku JAR.
  • W żądaniu Curl definiujemy parametry żądania, takie jak - URL i sposób żądania wraz z treścią odpowiedzi w sekcji „odpowiedź”. Oznacza to po prostu, że za każdym razem, gdy przychodzi żądanie GET z adresem URL / get / user / 1, należy odpowiedzieć określoną treścią odpowiedzi.

# 5) Po ustawieniu odpowiedzi skróconej (za pomocą powyższego żądania curl), możemy spróbować trafić w adres URL i sprawdzić, czy otrzymujemy odpowiedź skróconą z Wiremocka.

Spróbujmy kliknąć ten adres URL w przeglądarce - http: // localhost: 8080 / get / user / 1

Jeśli mapowanie zostało pomyślnie ustawione, powinieneś otrzymać odpowiedź, jak pokazano poniżej:

mapowanie zostało pomyślnie ustawione

Wraz z JUnit testuje jako konfigurację reguł JUnit

Serwer Wiremock może być używany z testami JUnit jako konfiguracją reguł JUnit. Dzięki temu JUnit dba o cykl życia Wiremock, tj. Uruchamia się i zatrzymuje Wiremock.

pytania do wywiadu na temat mavena i jenkinsa

Jest używany głównie w konfiguracjach, w których chcesz uruchamiać i zatrzymywać serwer po każdym teście.

Ma to swoje zalety w postaci izolacji i ma wysoki stopień konfigurowalności w przeciwieństwie do samodzielnej konfiguracji, w której wiele osób może korzystać z tego samego serwera i przechodzić nad odpowiedziami drugiej osoby.

Zobaczmy roboczy przykład tego podejścia:

# 1) Utwórz regułę JUnit dla serwera Wiremock. Ten krok jest zasadniczo podobny do etapu konfiguracji testu, w którym mówimy runnerowi JUnit, aby utworzył wystąpienie serwera Wiremock przed każdym testem i zatrzymał serwer po każdym teście.

Oznacza to również, że JUnit runner zajmie się uruchomieniem i zatrzymaniem serwera Wiremock, nie robiąc tego jawnie.

@Rule public WireMockRule wm = new WireMockRule(wireMockConfig().port(8080));

#dwa) Teraz napiszemy nasz test, w którym najpierw utworzymy naszego klienta (przy użyciu okHttp) do wykonywania żądań na żądanym punkcie końcowym.

// execute request through http client OkHttpClient client = new OkHttpClient(); Request request = new Request.Builder() .url('http://localhost:8080/test/abc') .get() .build();

# 3) Ale możesz zauważyć tutaj, że nadal nie ustawiliśmy żadnego kodu pośredniczącego do zwrócenia dla naszej instancji Wiremock. tj. powyższy klient zażąda adresu URL http: // localhost: 8080 / test / abc, który nie ma żadnego skonfigurowanego kodu pośredniczącego. W takim przypadku serwer Wiremock zwróci 404 brak treści.

# 4) Teraz, aby ustawić kod pośredniczący dla powyższego adresu URL dla naszej instancji serwera Wiremock, będziemy musieli wywołać statyczne metody pośredniczące Wiremocka, jak pokazano poniżej.

private void configureStubs() { configureFor('localhost', 8080); stubFor(get(urlEqualTo('/test/abc')) .willReturn(aResponse().withBody('Test success!'))); }

Tutaj widać, że używaliśmy kilku statycznych metod, takich jak configureFor, stubFor itd. Wszystkie te metody są częścią biblioteki Wiremock Java. (Szczegółowo przyjrzymy się tym metodom w następnym samouczku / sekcjach)

# 5) Teraz, po wykonaniu kroku konfiguracji, możemy po prostu wykonać żądanie za pośrednictwem klienta i zweryfikować odpowiedź (w zależności od tego, co jest skonfigurowane dla kodu pośredniczącego, aby powrócił przez Wiremock)

Podsumowując, oto jak wyglądałby cały przykładowy kod:

public class WiremockJunitTest { @Rule public WireMockRule wm = new WireMockRule(wireMockConfig().port(8080)); @Test public void assertWiremockSetup() throws IOException { // Arrange - setup wiremock stubs configureStubs(); // execute request through the http client OkHttpClient client = new OkHttpClient(); Request request = new Request.Builder() .url('http://localhost:8080/test/abc') .get() .build(); // Act - call the endpoint Response response = client.newCall(request).execute(); // Assert - verify the response assertEquals('Test success!', response.body().string()); verify(exactly(1),getRequestedFor(urlEqualTo('/test/abc'))); } // configure stubs for wiremock private void configureStubs() { configureFor('localhost', 8080); stubFor(get(urlEqualTo('/test/abc')) .willReturn(aResponse().withBody('Test success!'))); } }

Wymagane zależności

Jest dostępny jako:

  • Samodzielny plik JAR zawierający tylko zależność Wiremock.
  • Słoik na tłuszcz zawierający Wiremocka i wszystkie jego zależności.

Oba smaki są dostępne jako zależności Gradle i Maven. Więcej szczegółów jest dostępnych w oficjalnym repozytorium Maven tutaj

Samouczek wideo: Wiremock z testem JUnit

Wniosek

W tym samouczku omówiliśmy podstawowe funkcje Wiremocka i zobaczyliśmy, jak można go uruchomić jako samodzielny serwer i jako część testów JUnit przy użyciu reguł JUnit.

W skrócie poruszyliśmy również kwestię krojenia i omówimy to szczegółowo w następnym samouczku.

NEXT Tutorial

rekomendowane lektury

^