Meny

Wiremock Tutorial: Introduksjon til Wiremock

  • Hoved
  • Annen
  • Wiremock Tutorial: Introduksjon til Wiremock

wiremock tutorial introduction wiremock

Prøv Instrumentet Vårt For Å Eliminere Problemer

Denne innledende videoveiledningen vil forklare funksjonene til Wiremock og hvordan du kjører Wiremock som en frittstående server og som en del av JUnit-tester:

I denne opplæringen vil vi dekke de grunnleggende konseptene og detaljene rundt Wiremock-verktøyet. Den kan brukes som en frittstående HTTP-server, så vel som i JUnit-testene i henhold til kravene.

Dette er et mye brukt verktøy ettersom det er åpen kildekode og har et stort fellesskap av bidragsytere. Den kommer inn under kategorien verktøy for virtualisering av tjenester.

Wiremock Tool Introduksjon

Hva du vil lære:

Hva er Wiremock?

Enkelt sagt er Wiremock et hånlig oppsett for integrasjonstester. Det er rett og slett en mock-server som er svært konfigurerbar for å returnere et forventet svar for en gitt forespørsel.

Det brukes mye under utvikling og enda viktigere under integrasjonstesting mens et system eller en tjeneste snakker med en eller flere eksterne eller interne avhengigheter / tjenester.

La oss prøve å forstå mer om integrasjonstesting generelt og bli kjent med hvordan Wiremock kan bidra til å komme forbi disse utfordringene og gjøre livet vårt enklere.

Generelt, når ordet integrering kommer, er det som slår oss en slutt på integrasjon mellom to kommuniserende systemer. La oss nå se på det fra perspektivet til en applikasjon under test som bruker noen eksterne tjenester for å få jobben gjort.

For eksempel, la oss anta at vi bygger en applikasjon for online reise- eller billettsystem, og at vi har en modul for PNR-statuskontroll som treffer et eksternt API levert av Indian Railways.

Nå, hvordan kan vi integrere tester applikasjonen vår med de eksterne API-ene?

Det er to måter å gjøre dette på:

  • Først, er Enhetstest-tilnærmingen, der vi stikker grensesnittet som er gitt (eller opprettet internt), slik at systemet vårt tester / validerer den stubbede eller falske responsen selv før vi treffer den eksterne API-en. Dette er ingenting annet enn en enhetstest som prøver å spotte en ekstern avhengighet.
  • Sekund tester med noen testmiljø (eller det faktiske produksjonsmiljøet) av de eksterne avhengighetene. Imidlertid er det flere utfordringer med den tilnærmingen som nevnt nedenfor:
    • Eksterne API-systemer er kanskje ikke alltid tilgjengelige. dvs. vi er sterkt avhengige av eller avhengige av eksterne systemer, og enhver nedetid der vil påvirke testene våre og indirekte utviklings- / frigjøringsprosessen.
    • For det andre kan eksterne API-er eller ikke ha et testmiljø. For eksempel, et PNR-statuskontroll-API kan alltid kreve ekte PNR-numre for å hente og returnere svar.
    • Mange ganger er det kostnader forbundet med å treffe en API. For eksempel, antar at PNR-sjekk API krever Rs 100 for hver 1000 forespørsler. Siden integrasjonstester vanligvis kjøres i løpet av hver regresjon (og mesteparten av tiden med hver forpliktelse), er det kanskje ikke en kostnadseffektiv løsning å treffe et slikt API som koster oss selv for testformål.
    • En ekstern API kan ikke konfigureres for å returnere ønsket svar. Selv om det er mulig, må du opprette mange testdata for å sikre forskjellige svar for forskjellige forespørsel.
      For eksempel, du vil teste feilscenarier som at et API returnerer forskjellige statuskoder for forskjellige typer data. Nå som svaret ikke er under vår kontroll, må vi lage flere datasett for å validere forskjellige mulige scenarier eller utfall.

La oss forstå disse konseptene ved hjelp av diagrammet nedenfor.

Her sammenligner vi både tilnærmingene til integrasjonstesting, dvs. uten en mock-server ved hjelp av en faktisk implementering av den eksterne avhengigheten, og ved hjelp av mock-serveren (Wiremock) som spotter svar på forespørslene som mottas for avhengigheten.

I sistnevnte tilfelle reduserer det avhengighet og avhengighet av den faktiske implementeringen av avhengighet sterkt og gir mange konfigurasjonsmuligheter uten å gå på kompromiss med kvalitet og leveringsplaner.

Wiremock-konsepter

Hvordan svarer Wiremock på en gitt forespørsel?

Som vi vet er Wiremock en programmatisk Mock-server. Måten den svarer på en gitt forespørsel er ved å lagre alle relevante kartlegginger (eller spottede svar) i en mappe kalt 'mappings'

Det er en matcherkomponent i Wiremock som samsvarer med innkommende forespørsler til de lagrede tilordningene, og hvis en vellykket kamp returneres, returneres den første slike match som svar på den gitte forespørselen.

I tilfelle du bruker den frittstående versjonen av Wiremock, når du kjører Wiremock-serveren, vil du se mappingsmappen som blir opprettet i Wiremock installasjon / jar-plasseringskatalogen.

Videoopplæring: Introduksjon til Wiremock Tool

youtube til mp3 converter uten virus

Hvordan bruke Wiremock?

La oss nå se hvordan vi kan bruke dette verktøyet med integrasjonstestene våre.

Den kan brukes på følgende måter.

En frittstående Wiremock-server

Som en frittstående server kan du bare lage en enkel Java-applikasjon med Maven / Gradle avhengighet for Wiremock, og beholde den som en pågående prosess.

Dette er et godt alternativ når du vil være vert for din frittstående server på en maskin og bruke den som en eneste mocking-server for hele prosjektet eller teamet. I frittstående modus kan dette verktøyet også utføres ved å laste ned den frittstående krukken som er tilgjengelig her og bare kjør glasset.

For eksempel, antar at du vil distribuere din frittstående Wiremock-forekomst til en eller annen server på skyen eller en lokal server, så kan du ganske enkelt kjøre denne krukken og bruke system-IP-en til å bruke den som en vertstjeneste.

La oss se noen trinn for å kjøre dette i frittstående modus (og konfigurere forskjellige ting som porter, mapping av mapper osv.)

#1) Kjør Wiremock-krukken fra terminalen (eller ledeteksten for Windows-brukere) som alle andre JAR-filer (fra installasjonskatalogen for Wiremock jar).

java -jar wiremock-standalone-2.25.1.jar

#to) Som standard kjører Wiremock på localhost: 8080 (hvis porten er ledig for bruk, vil kommandoen ovenfor starte Wiremock-serveren i en frittstående modus), og du ser utdataene som nedenfor.

Wiremock kjører på localhost

# 3) Nå når serveren starter, kan du besøke hvilken som helst URL på localhost: 8080

For eksempel, http: // localhost: 8080 / get / user / 1 - Ettersom det for øyeblikket ikke er noen håner som blir satt, får du et svar som vist nedenfor.

Wiremock-svar

# 4) La oss nå prøve å sette opp en enkel stub / mock for denne URL-en og prøve å slå URL-en tilbake. Vi vil deretter validere at å treffe den samme URL-en nå returnerer det spottet eller stubbet svaret.

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

La oss prøve å forstå denne CURL-forespørselen først:

  • Vi lager en CURL POST-forespørsel til http: // localhost: 8080 / __ admin / mappings / new - Dette er stedet der alle tilordningene vil bli lagret for Wiremock-serveren som vi utførte / startet gjennom JAR-filen.
  • I Curl-forespørselen definerer vi forespørselsparametere som - URL og forespørselsmetode sammen med svaret i 'svar' -delen. Dette innebærer ganske enkelt at når en GET-forespørsel kommer inn med URL / get / user / 1, så svarer med det angitte svaret.

# 5) Når den stubbede responsen er angitt (ved hjelp av den ovennevnte curl-forespørselen), kan vi prøve å trykke URL-en og se om vi får tilbake stubbed-svaret fra Wiremock.

La oss prøve å trykke denne nettadressen i nettleseren - http: // localhost: 8080 / get / user / 1

Hvis kartleggingen ble angitt, bør du få et svar som vist nedenfor:

kartleggingen ble angitt

Sammen med JUnit-tester som JUnit-regelkonfigurasjon

Wiremock-server kan brukes med JUnit-tester som et JUnit Rule-oppsett. Med dette tar JUnit seg av Wiremock-livssyklusen, dvs. Wiremock starter og stopper.

avslappende spørsmål om nettjenester som tester intervjuer

Den brukes mest i oppsett der du vil starte og stoppe serveren etter hver test.

Dette har sine egne fordeler ved å være isolert og har en høy grad av konfigurerbarhet i motsetning til et frittstående oppsett der flere mennesker kan ende opp med å bruke den samme serveren og gå over hverandres stubbede responser.

La oss se et fungerende eksempel på denne tilnærmingen:

#1) Opprett en JUnit-regel for Wiremock-serveren. Dette trinnet er egentlig som et testoppsettstrinn der vi forteller JUnit-løperen å instansiere Wiremock-serveren før hver test og stoppe serveren etter hver test.

Hva dette også betyr er at JUnit runner tar seg av å starte og stoppe Wiremock-serveren uten å gjøre det eksplisitt.

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

#to) Nå skal vi skrive testen vår der vi først oppretter vår klient (ved hjelp av okHttp) for å utføre forespørsler mot ønsket sluttpunkt.

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

# 3) Men du kan merke her at vi fremdeles ikke har satt inn noen stub som skal returneres for vår Wiremock-forekomst. dvs. at ovenstående klient vil be om en URL http: // localhost: 8080 / test / abc som ikke har noen konfigurert stub. I dette tilfellet vil Wiremock-serveren returnere et 404-innhold.

# 4) For å sette en stub for URL-adressen ovenfor for Wiremock-serverforekomsten, må vi ringe Wiremocks stub statiske metoder som vist nedenfor.

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

Her kan du se at vi har brukt et par statiske metoder som configureFor, stubFor, etc. Alle disse metodene er en del av Wiremock Java-biblioteket. (Vi vil se på disse metodene i detalj i vår neste opplæring / seksjoner)

# 5) Nå med konfigurasjonstrinnet gjort, kan vi bare utføre forespørselen gjennom klienten og validere svaret (avhengig av hva som er konfigurert for at stubben skal returnere gjennom Wiremock)

For å oppsummere, her er hvordan hele kodeeksemplet vil se ut:

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!'))); } }

Avhengigheter kreves

Den er tilgjengelig som:

  • En frittstående JAR som bare inneholder Wiremock-avhengigheten.
  • En fettkrukke som inneholder Wiremock og alle dens avhengigheter.

Begge smakene er tilgjengelige som avhengigheter Gradle og Maven. Mer informasjon er tilgjengelig på det offisielle Maven-depotet her

Videoopplæring: Wiremock With JUnit Test

Konklusjon

I denne opplæringen gikk vi gjennom de grunnleggende funksjonene i Wiremock og så hvordan den kan kjøres som en frittstående server og som en del av JUnit-testene ved hjelp av JUnit-regler.

Vi berørte også stubb i korte trekk, og vi vil dekke det i detalj i vår neste opplæring.

NESTE veiledning

Anbefalt lesing

^