Meny

Wiremock-handledning: Introduktion till Wiremock

  • Huvud
  • Övrig
  • Wiremock-handledning: Introduktion till Wiremock

wiremock tutorial introduction wiremock

Prova Vårt Instrument För Att Eliminera Problem

Denna introduktionsvideohandledning kommer att förklara funktionerna i Wiremock och hur man kör Wiremock som en fristående server och som en del av JUnit-tester:

I denna handledning kommer vi att täcka de grundläggande begreppen och detaljerna kring Wiremock-verktyget. Den kan användas som en fristående HTTP-server såväl som inom JUnit-testerna enligt kraven.

Detta är ett kraftigt använt verktyg eftersom det är öppen källkod och har en stor grupp av bidragsgivare. Det faller under kategorin Service virtualiseringsverktyg.

Wiremock Tool Introduktion

Vad du kommer att lära dig:

Vad är Wiremock?

Enkelt uttryckt är Wiremock en hånfull installation för integrationstester. Det är helt enkelt en mock-server som är mycket konfigurerbar för att returnera ett förväntat svar för en given begäran.

Det används ofta under utveckling och ännu viktigare under integrationstest medan ett system eller en tjänst pratar med en eller flera externa eller interna beroenden / tjänster.

Låt oss försöka förstå mer om integrationstester i allmänhet och lära oss hur Wiremock kan hjälpa till att komma förbi dessa utmaningar och göra våra liv enklare.

I allmänhet, när ordet integration kommer, är det som slår oss ett slut-till-slut-integration mellan två kommunikationssystem. Nu ska vi titta på det ur ett applikations test som använder en extern tjänst för att få jobbet gjort.

Till exempel, låt oss anta att vi bygger en applikation för online-rese- eller biljettsystem och att vi har en modul för PNR-statuskontroll som träffar ett externt API från Indian Railways.

Hur kan vi nu testa vår applikation med de externa API: erna?

Det finns två sätt att göra detta:

  • Först, är enhetstestmetoden, där vi stubbar gränssnittet som tillhandahålls (eller skapas internt) så att vårt system testar / validerar det stubbade eller falska svaret även innan vi träffar det externa API: et. Detta är ingenting annat än ett enhetstest som försöker håna ett externt beroende.
  • Andra testar med någon testmiljö (eller den faktiska produktionsmiljön) av externa beroenden. Det finns dock flera utmaningar med det tillvägagångssätt som nämns nedan:
    • Externa API-system kanske inte alltid är tillgängliga. dvs. vi är starkt beroende eller beroende av externa system och eventuell stillestånd där kommer att påverka våra tester och indirekt utvecklings- / release-processen.
    • För det andra kan externa API: er kanske eller inte ha en testmiljö. Till exempel, ett PNR-statuskontroll-API kan alltid kräva riktiga PNR-nummer för att hämta och returnera svar.
    • Många gånger finns det kostnader för att slå ett API. Till exempel, antar att PNR-kontroll API tar ut Rs 100 för varje 1000 förfrågningar. Eftersom integrationstester vanligtvis körs under varje regression (och oftast vid varje förpliktelse), kanske det inte är en kostnadseffektiv lösning att träffa ett sådant API som kostar oss även för teständamål.
    • Ett externt API kan inte konfigureras för att returnera önskat svar. Även om det är möjligt måste du skapa en hel del testdata för att säkerställa olika svar för olika begäraningångar.
      Till exempel, du vill testa felscenarier som att ett API returnerar olika statuskoder för olika typer av data. Eftersom svaret inte är under vår kontroll måste vi skapa flera uppsättningar data för att validera olika möjliga scenarier eller resultat.

Låt oss förstå dessa begrepp med hjälp av nedanstående diagram.

Här jämför vi både metoderna för integrationstestning, dvs. utan en mock-server som använder en faktisk implementering av det externa beroendet och använder mock-servern (Wiremock) som hånar svar på de begärda mottagningarna för beroendet.

I det senare fallet minskar det avsevärt beroende och beroende av det faktiska genomförandet av beroende och ger många konfigurationsmöjligheter utan att kompromissa med kvalitet och leveransscheman.

Wiremock-koncept

Hur svarar Wiremock på en given begäran?

Som vi vet är Wiremock en programmatisk Mock-server, hur den svarar på en given begäran är att lagra alla relevanta mappningar (eller hånade svar) i en mapp som heter 'mappings'

Det finns en matchningskomponent i Wiremock som matchar inkommande förfrågningar till de lagrade mappningarna och om en lyckad matchning returneras returneras den första matchningen som svar för den givna begäran.

Om du använder den fristående versionen av Wiremock, när du kör Wiremock-servern, ser du mappningsmappen som kommer att skapas i Wiremock-installations- / jar-platskatalogen.

Videohandledning: Introduktion till Wiremock Tool

sql utvecklare intervju frågor för 4 års erfarenhet

Hur man använder Wiremock?

Låt oss nu se hur vi kan använda det här verktyget med våra integrationstester.

Den kan användas på följande sätt.

En fristående Wiremock-server

Som en fristående server kan du bara skapa en enkel Java-applikation med Maven / Gradle-beroende för Wiremock och behålla den som en pågående process.

Detta är ett bra alternativ när du vill vara värd för din fristående server på någon maskin och använda den som en enda spottande server för hela projektet eller teamet. I fristående läge kan det här verktyget också köras genom att ladda ner den fristående burken här och kör bara burken.

Till exempel, antar att du vill distribuera din fristående Wiremock-instans till någon server på molnet eller en lokal server, då kan du helt enkelt köra den här burken och använda systemets IP för att använda den som en värdtjänst.

Låt oss se några steg för att köra detta i fristående läge (och konfigurera olika saker som portar, mappmappar osv.)

# 1) Kör Wiremock-burken från terminalen (eller kommandotolken för Windows-användare) som alla andra JAR-filer (från installationskatalogen för Wiremock jar).

java -jar wiremock-standalone-2.25.1.jar

#två) Som standard körs Wiremock på localhost: 8080 (om porten är fri att använda kommer kommandot ovan att starta Wiremock-servern i ett fristående läge) och du ser utdata som nedan.

Wiremock körs på localhost

# 3) Nu när servern startar kan du besöka vilken webbadress som helst på localhost: 8080

Till exempel, http: // localhost: 8080 / get / user / 1 - Eftersom det för närvarande inte ställs in några mocks får du ett svar som visas nedan.

Wiremock-svar

# 4) Låt oss nu försöka ställa in en enkel stub / mock för den här webbadressen och försöka slå tillbaka webbadressen igen. Vi kommer sedan att bekräfta att träff på samma URL nu returnerar det hånade eller stubbade 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

Låt oss först förstå den här CURL-begäran:

  • Vi gör en CURL POST-begäran till http: // localhost: 8080 / __ admin / mappings / new - Det här är den plats där alla mappningar kommer att lagras för Wiremock-servern som vi körde / startade genom JAR-filen.
  • I Curl-förfrågan definierar vi förfrågningsparametrar som - URL och begärningsmetod tillsammans med svarstypen i avsnittet 'svar'. Detta innebär helt enkelt att när en GET-begäran kommer in med URL / get / user / 1 så svarar den med den angivna svarsdelen.

# 5) När det stubbade svaret är inställt (med hjälp av ovanstående curlbegäran) kan vi försöka slå URL och se om vi får tillbaka stubbed-svar från Wiremock.

Låt oss försöka slå den här webbadressen i webbläsaren - http: // localhost: 8080 / get / user / 1

Om kartläggningen har ställts in framgångsrikt bör du få ett svar enligt nedan:

mappningen har ställts in

Tillsammans med JUnit-tester som JUnit-regelkonfiguration

Wiremock-servern kan användas med JUnit-tester som en JUnit-regelinställning. Med detta tar JUnit hand om Wiremock-livscykeln, dvs. Wiremock startar och stoppar.

vilsam webbtjänst testar intervjufrågor

Det används mest i inställningar där du vill starta och stoppa servern efter varje test.

Detta har sina egna fördelar med att vara isolerad och har en hög grad av konfigurerbarhet i motsats till en fristående installation där flera personer kan hamna på samma server och gå över varandras stubbed-svar.

Låt oss se ett fungerande exempel på denna metod:

# 1) Skapa en JUnit-regel för Wiremock-servern. Detta steg är i huvudsak som ett testinställningssteg där vi ber JUnit-löparen att starta Wiremock-servern före varje test och stoppa servern efter varje test.

Vad detta också betyder är att JUnit runner kommer att ta hand om att starta och stoppa Wiremock-servern utan att uttryckligen göra det.

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

#två) Nu ska vi skriva vårt test där vi först skapar vår klient (med okHttp) för att utföra förfrågningar mot önskad slutpunkt.

// 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 märka här att vi fortfarande inte har ställt in någon stub som ska returneras för vår Wiremock-instans. dvs ovanstående klient kommer att begära en URL http: // localhost: 8080 / test / abc som inte har någon konfigurerad stub. I det här fallet returnerar Wiremock-servern ett 404-innehåll.

# 4) För att ställa in en stub för ovanstående URL för vår Wiremock-serverinstans måste vi anropa Wiremocks stub statiska metoder enligt nedan.

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

Här kan du se att vi har använt ett par statiska metoder som configureFor, stubFor, etc. Alla dessa metoder är en del av Wiremock Java-biblioteket. (Vi kommer att titta på dessa metoder i detalj i vår nästa handledning / avsnitt)

# 5) Nu när konfigurationssteget är klart kan vi helt enkelt utföra begäran via klienten och validera svaret (beroende på vad som är konfigurerat för att stubben ska återvända via Wiremock)

För att sammanfatta, så här ser hela kodprovet 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!'))); } }

Beroenden krävs

Den finns som:

  • En fristående JAR som bara innehåller Wiremock-beroende.
  • En fet burk som innehåller Wiremock och alla dess beroende.

Båda smakerna finns som beroende av Gradle och Maven. Mer information finns på det officiella Maven-förvaret här

Videohandledning: Wiremock With JUnit Test

Slutsats

I den här guiden gick vi igenom de grundläggande funktionerna i Wiremock och såg hur den kan köras som en fristående server och som en del av JUnit-testerna med JUnit-regler.

Vi berörde också stubbning i korthet och vi kommer att täcka det i detalj i vår nästa handledning.

NÄSTA självstudie

Rekommenderad läsning

^