Menu

Wiremock Tutorial: Introduktion til Wiremock

wiremock tutorial introduction wiremock

Prøv Vores Instrument Til At Fjerne Problemer

Denne introduktionsvideovejledning forklarer funktionerne i Wiremock og hvordan man kører Wiremock som en uafhængig server og som en del af JUnit Tests:

I denne vejledning vil vi dække de grundlæggende koncepter og detaljer omkring Wiremock-værktøjet. Den kan bruges som en enkeltstående HTTP-server såvel som inden for JUnit-testene i henhold til kravene.

Dette er et meget brugt værktøj, da det er open source og har et stort samfund af bidragydere. Det kommer under kategorien Service virtualiseringsværktøjer.

Wiremock Tool Introduktion

Hvad du lærer:

Hvad er Wiremock?

Enkelt sagt er Wiremock en mocking-opsætning til integrationstest. Det er simpelthen en mock-server, der er meget konfigurerbar til at returnere et forventet svar til en given anmodning.

Det bruges i vid udstrækning under udvikling og endnu vigtigere under integrationstest, mens et system eller en tjeneste taler til en eller flere eksterne eller interne afhængigheder / tjenester.

Lad os prøve at forstå mere om integrationstest generelt og lære, hvordan Wiremock kan hjælpe med at komme forbi disse udfordringer og gøre vores liv lettere.

Generelt, når ordet integration kommer, er det, der rammer os, en ende til slut-integration mellem to kommunikationssystemer. Lad os nu se på det fra perspektivet af en applikation under test, der bruger en ekstern service til at få arbejdet gjort.

For eksempel, Lad os antage, at vi bygger en applikation til online rejse- eller billetsystem, og at vi har et modul til PNR-statuskontrol, der rammer en ekstern API leveret af Indian Railways.

Hvordan kan vi nu integrere vores applikationstest med de eksterne API'er?

Der er to måder at gøre dette på:

  • Først, er enhedstestmetoden, hvor vi stubber den interface, der leveres (eller oprettes internt), så vores system tester / validerer det stubede eller falske svar, selv før vi rammer den eksterne API. Dette er intet andet end en enhedstest, der prøver at spotte en ekstern afhængighed.
  • Sekund tester med et eller andet testmiljø (eller det faktiske produktionsmiljø) af de eksterne afhængigheder. Der er dog flere udfordringer med denne tilgang, som nævnt nedenfor:
    • Eksterne API-systemer er muligvis ikke altid tilgængelige. dvs. vi er stærkt afhængige eller afhængige af eksterne systemer, og enhver nedetid der vil påvirke vores tests og indirekte udviklings- / frigivelsesprocessen.
    • For det andet har eksterne API'er måske eller måske ikke et testmiljø. For eksempel, en PNR-statuskontrol-API kræver muligvis altid rigtige PNR-numre for at hente og returnere svar.
    • Mange gange er der omkostninger forbundet med at ramme en API. For eksempel, Antag, at PNR-kontrol API opkræver Rs 100 for hver 1000 anmodninger. Da integrationstest normalt køres under hver regression (og det meste af tiden med hver forpligtelse), er det muligvis ikke en omkostningseffektiv løsning at ramme en sådan API, der koster os selv til testformål.
    • En ekstern API kan ikke konfigureres til at returnere det ønskede svar. Selv hvis det er muligt, bliver du nødt til at oprette en masse testdata for at sikre forskellige svar for forskellige anmodninger.
      For eksempel, du vil teste fejlscenarier, som om en API returnerer forskellige statuskoder for forskellige typer data. Nu da svaret ikke er under vores kontrol, bliver vi nødt til at oprette flere datasæt for at validere forskellige mulige scenarier eller resultater.

Lad os forstå disse begreber ved hjælp af nedenstående diagram.

Her sammenligner vi begge tilgange til integrationstest, dvs. uden en mock-server ved hjælp af en faktisk implementering af den eksterne afhængighed og ved hjælp af mock-serveren (Wiremock), som spotter svar på de modtagne anmodninger om afhængigheden.

I sidstnævnte tilfælde reducerer det stærkt afhængighed og afhængighed af den faktiske implementering af afhængighed og giver en masse konfigurationsfunktioner uden at gå på kompromis med kvalitet og leveringsplaner.

Wiremock-koncepter

Hvordan reagerer Wiremock på en given anmodning?

Som vi ved, er Wiremock en programmatisk Mock-server, den måde den reagerer på en given anmodning på er ved at gemme alle relevante tilknytninger (eller spottede svar) i en mappe kaldet 'kortlægninger'

Der er en matcherkomponent i Wiremock, der matcher indgående anmodninger til de gemte tilknytninger, og hvis et vellykket match returneres, returneres det første sådant match som svar på den givne anmodning.

Hvis du bruger den enkeltstående version af Wiremock, når du kører Wiremock-serveren, vil du se mappen mappings, der oprettes i Wiremock-installations- / jar-placeringsmappen.

Video tutorial: Introduktion til Wiremock Tool

dijkstras algoritme ved hjælp af prioritetskø java

Sådan bruges Wiremock?

Lad os nu se, hvordan vi kan bruge dette værktøj til vores integrationstest.

Det kan bruges på følgende måder.

En standalone Wiremock-server

Som en enkeltstående server kan du bare oprette en simpel Java-applikation med Maven / Gradle-afhængighed for Wiremock og beholde den som en kørende proces.

Dette er et godt alternativ, når du vil være vært for din enkeltstående server på en maskine og bruge den som en enkelt mocking-server til hele projektet eller teamet. I standalone-tilstand kan dette værktøj også udføres ved at downloade den tilgængelige standalone jar her og kør bare krukken.

For eksempel, Antag, at du vil distribuere din Wiremock-enkeltstående forekomst til en eller anden server på cloud eller en lokal server, så kan du simpelthen køre denne krukke og bruge systemets IP til at bruge den som en hostet tjeneste.

Lad os se nogle trin til at køre dette i standalone-tilstand (og konfigurere forskellige ting som porte, kortlægning af mapper osv.)

# 1) Kør Wiremock-jar fra terminalen (eller kommandoprompten til Windows-brugere) som enhver anden JAR-fil (fra installationsmappen til Wiremock jar).

java -jar wiremock-standalone-2.25.1.jar

#to) Som standard kører Wiremock på localhost: 8080 (hvis porten er gratis til brug, vil ovenstående kommando starte Wiremock-serveren i en uafhængig tilstand), og du ser output som nedenfor.

Wiremock kører på localhost

# 3) Nu når serveren starter, kan du besøge enhver URL på localhost: 8080

For eksempel, http: // localhost: 8080 / get / user / 1 - Da der i øjeblikket ikke er indstillet nogen mocks, får du et svar som vist nedenfor.

Wiremock-svar

# 4) Lad os nu prøve at oprette en simpel stub / mock til denne URL og prøve at slå URL'en tilbage. Vi bekræfter derefter, at det at slå den samme URL nu returnerer det spottede eller stubede svar.

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

Lad os prøve at forstå denne CURL-anmodning først:

  • Vi fremsætter en CURL POST-anmodning til http: // localhost: 8080 / __ admin / mappings / new - Dette er nu det sted, hvor alle tilknytningerne gemmes til Wiremock-serveren, som vi udførte / startede gennem JAR-filen.
  • I Curl-anmodningen definerer vi anmodningsparametre som - URL og anmodningsmetode sammen med svarteksten i afsnittet 'svar'. Dette indebærer simpelthen, at når en GET-anmodning kommer ind med URL / get / user / 1, skal du svare med det angivne svarorgan.

# 5) Når det stubbede svar er indstillet (ved hjælp af ovenstående curl-anmodning), kan vi prøve at trykke på URL'en og se om vi får stubbed-svar tilbage fra Wiremock.

Lad os prøve at ramme denne URL i browseren - http: // localhost: 8080 / get / user / 1

Hvis kortlægningen blev indstillet med succes, skulle du få et svar som vist nedenfor:

kortlægning blev indstillet

Sammen med JUnit-test som JUnit-regelkonfiguration

Wiremock-server kan bruges med JUnit-tests som en JUnit Rule-opsætning. Med dette tager JUnit sig af Wiremock-livscyklussen, dvs. Wiremock starter og stopper.

qa test interview spørgsmål til erfarne

Det bruges mest i opsætninger, hvor du gerne vil starte og stoppe serveren efter hver test.

Dette har sine egne fordele ved at være isoleret og har en høj grad af konfigurerbarhed i modsætning til en enkeltstående opsætning, hvor flere mennesker kan ende med at bruge den samme server og træde over hinandens stubede svar.

Lad os se et fungerende eksempel på denne tilgang:

# 1) Opret en JUnit-regel til Wiremock-serveren. Dette trin er i det væsentlige som et testopsætningstrin, hvor vi fortæller JUnit-løberen at instantiere Wiremock-serveren før hver test og stoppe serveren efter hver test.

Hvad dette også betyder, er at JUnit runner sørger for at starte og stoppe Wiremock-serveren uden eksplicit at gøre det.

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

#to) Nu skriver vi vores test, hvor vi først opretter vores klient (ved hjælp af okHttp) til at udføre anmodninger mod det ønskede 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 bemærke her, at vi stadig ikke har indstillet nogen stub, der skal returneres til vores Wiremock-instans. dvs. ovenstående klient vil anmode om en URL http: // localhost: 8080 / test / abc, der ikke har nogen konfigureret stub. I dette tilfælde returnerer Wiremock-serveren et 404 intet indhold.

# 4) For at indstille en stub til ovenstående URL til vores Wiremock-serverinstans, bliver vi nødt til at kalde 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 brugt et par statiske metoder som configureFor, stubFor osv. Alle disse metoder er en del af Wiremock Java-biblioteket. (Vi vil se på disse metoder i detaljer i vores næste tutorial / sektioner)

# 5) Nu med konfigurationstrinnet udført, kan vi simpelthen udføre anmodningen gennem klienten og validere svaret (afhængigt af hvad der er konfigureret til, at stuben vender tilbage gennem Wiremock)

For at opsummere, her er hvordan hele kodeeksemplet ser ud:

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

Afhængigheder påkrævet

Den fås som:

  • En standalone JAR, der kun indeholder Wiremock-afhængighed.
  • En fedt krukke indeholdende Wiremock og alle dens afhængigheder.

Begge varianter er tilgængelige som Gradle og Maven afhængigheder. Flere detaljer findes på det officielle Maven-arkiv her

Videovejledning: Wiremock With JUnit Test

Konklusion

I denne vejledning gik vi gennem de grundlæggende funktioner i Wiremock og så, hvordan den kan køres som en enkeltstående server og som en del af JUnit-testene ved hjælp af JUnit-regler.

Vi berørte også stubning kort, og vi vil dække det detaljeret i vores næste vejledning.

NÆSTE vejledning

Anbefalet læsning

^