wiremock tutorial introduction wiremock
In deze inleidende video-tutorial worden de functies van Wiremock uitgelegd en hoe u Wiremock als zelfstandige server en als onderdeel van JUnit-tests kunt uitvoeren:
In deze tutorial behandelen we de basisconcepten en details van de Wiremock-tool. Het kan worden gebruikt als een stand-alone HTTP-server en binnen de JUnit-tests volgens de vereisten.
Dit is een veelgebruikte tool omdat het open-source is en een grote community van bijdragers heeft. Het valt onder de categorie Servicevirtualisatietools.
Wat je leert:
Wat is Wiremock?
In eenvoudige bewoordingen is Wiremock een spottende opstelling voor integratietests. Het is gewoon een nepserver die in hoge mate kan worden geconfigureerd om een verwacht antwoord op een bepaald verzoek te retourneren.
Het wordt veel gebruikt tijdens de ontwikkeling en, nog belangrijker, tijdens integratietests, terwijl een systeem of service praat met een of meerdere externe of interne afhankelijkheden / services.
Laten we proberen om meer te begrijpen over integratietests in het algemeen en om te zien hoe Wiremock kan helpen om die uitdagingen te overwinnen en ons leven gemakkelijker te maken.
Over het algemeen, als het woord integratie komt, valt ons op dat de integratie tussen 2 communicerende systemen van begin tot eind komt. Laten we het nu bekijken vanuit het perspectief van een applicatie die wordt getest en die een externe service gebruikt om de klus te klaren.
Bijvoorbeeld, Laten we aannemen dat we een applicatie bouwen voor een online reis- of ticketingsysteem en dat we een module hebben voor PNR-statuscontrole, die een externe API gebruikt die wordt geleverd door Indian Railways.
Hoe kunnen we nu onze applicatie testen met de externe API's?
U kunt dit op twee manieren doen:
- Eerste, is de unit-testaanpak, waarbij we de interface die wordt aangeboden (of intern gemaakt) stubben, zodat ons systeem de verstopte of nepreactie test / valideert zelfs voordat de externe API wordt gebruikt. Dit is niets anders dan een unit-test die probeert een externe afhankelijkheid te bespotten.
- Tweede test met een testomgeving (of de daadwerkelijke productieomgeving) van de externe afhankelijkheden. Er zijn echter verschillende uitdagingen met die benadering, zoals hieronder vermeld:
- Externe API-systemen zijn mogelijk niet altijd beschikbaar. d.w.z. we zijn sterk afhankelijk van of afhankelijk van externe systemen en elke downtime daar heeft invloed op onze tests en indirect op het ontwikkelings- / releaseproces.
- Ten tweede kunnen externe API's al dan niet een testomgeving hebben. Bijvoorbeeld, een PNR-statuscontrole-API vereist mogelijk altijd echte PNR-nummers om reacties op te halen en terug te sturen.
- Vaak zijn er kosten verbonden aan het raken van een API. Bijvoorbeeld, Stel dat PNR-controle API Rs 100 in rekening brengt voor elke 1000 verzoeken. Aangezien integratietests meestal worden uitgevoerd tijdens elke regressie (en meestal bij elke commit), is het misschien geen kosteneffectieve oplossing om zo'n API te gebruiken die ons zelfs voor testdoeleinden kost.
- Een externe API kan niet worden geconfigureerd om het gewenste antwoord te retourneren. Zelfs als het mogelijk is, moet u veel testgegevens maken om ervoor te zorgen dat verschillende reacties op verschillende verzoeken worden ingevoerd.
Bijvoorbeeld, u wilt foutscenario's testen zoals een API verschillende statuscodes retourneert voor verschillende soorten gegevens. Omdat we geen controle hebben over de respons, moeten we meerdere sets gegevens maken om verschillende mogelijke scenario's of uitkomsten te valideren.
Laten we deze concepten begrijpen met behulp van het onderstaande diagram.
Hier vergelijken we beide benaderingen van integratietests, d.w.z. zonder een nepserver met behulp van een daadwerkelijke implementatie van de externe afhankelijkheid en met behulp van de nepserver (Wiremock) die de reacties op de ontvangen verzoeken voor de afhankelijkheid bespot.
In het laatste geval vermindert het de afhankelijkheid en afhankelijkheid van de feitelijke implementatie van afhankelijkheid aanzienlijk en biedt het veel configuratiemogelijkheden zonder concessies te doen aan kwaliteit en leveringsschema's.
Hoe reageert Wiremock op een gegeven verzoek?
Zoals we weten, is Wiremock een programmatische Mock-server, de manier waarop het reageert op een bepaald verzoek is door alle relevante toewijzingen (of bespotte antwoorden) op te slaan in een map met de naam 'toewijzingen'
Er is een matcher-component van Wiremock die inkomende verzoeken koppelt aan de opgeslagen toewijzingen en als een succesvolle match wordt geretourneerd, wordt de eerste dergelijke match geretourneerd als het antwoord op het gegeven verzoek.
Als u de zelfstandige versie van Wiremock gebruikt, ziet u, zodra u de Wiremock-server uitvoert, de map met toewijzingen die wordt gemaakt in de Wiremock install / jar-locatiedirectory.
Video-tutorial: inleiding tot Wiremock Tool
wat te gebruiken in plaats van ccleaner
Hoe Wiremock te gebruiken?
Laten we nu eens kijken hoe we deze tool kunnen gebruiken met onze integratietests.
Het kan op de volgende manieren worden gebruikt.
Een zelfstandige Wiremock-server
Als zelfstandige server kunt u gewoon een eenvoudige Java-applicatie maken met Maven / Gradle-afhankelijkheid voor Wiremock en deze als een lopend proces behouden.
Dit is een goed alternatief als u uw stand-alone server op een computer wilt hosten en deze wilt gebruiken als een enkele mocking-server voor het hele project of team. In de stand-alone modus kan deze tool ook worden uitgevoerd door de beschikbare stand-alone jar te downloaden hier en laat gewoon de pot draaien.
Bijvoorbeeld, Stel dat u uw Wiremock stand-alone instantie wilt implementeren op een server in de cloud of een lokale server, dan kunt u deze jar eenvoudig uitvoeren en het systeem-IP gebruiken om het als een gehoste service te gebruiken.
Laten we wat zien stappen om dit in stand-alone modus uit te voeren (en verschillende dingen te configureren zoals poorten, mappen in kaart brengen, enz.)
# 1) Voer de Wiremock-jar uit vanaf de terminal (of opdrachtprompt voor Windows-gebruikers) zoals elk ander JAR-bestand (vanuit de installatiedirectory van Wiremock jar).
#twee) Wiremock draait standaard op localhost: 8080 (als de poort vrij is voor gebruik, start de bovenstaande opdracht de Wiremock-server in een zelfstandige modus) en je zult de uitvoer zien zoals hieronder.
# 3) Zodra de server start, kunt u elke URL op localhost: 8080 bezoeken
Bijvoorbeeld, http: // localhost: 8080 / get / user / 1 - Aangezien er op dit moment geen schijnwerpers worden ingesteld, krijg je een reactie zoals hieronder weergegeven.
# 4) Laten we nu proberen een eenvoudige stub / mock in te stellen voor deze URL en de URL nogmaals proberen terug te halen. We zullen dan valideren dat het raken van dezelfde URL nu het bespotte of stompe antwoord retourneert.
Laten we eerst dit CURL-verzoek proberen te begrijpen:
- We doen een CURL POST-verzoek aan http: // localhost: 8080 / __ admin / mappings / new - Dit is nu de locatie waar alle toewijzingen worden opgeslagen voor de Wiremock-server die we hebben uitgevoerd / gestart via het JAR-bestand.
- In het Curl-verzoek definiëren we verzoekparameters zoals - URL en verzoekmethode, samen met de antwoordtekst in de sectie 'antwoord'. Dit houdt simpelweg in dat wanneer een GET-verzoek binnenkomt met URL / get / user / 1, dan wordt gereageerd met de opgegeven antwoordtekst.
# 5) Zodra het afgekapte antwoord is ingesteld (met behulp van het bovenstaande curl-verzoek), kunnen we proberen de URL te raken en kijken of we het afgeknotte antwoord terugkrijgen van de Wiremock.
Laten we proberen deze URL in de browser te gebruiken - http: // localhost: 8080 / get / user / 1
Als de mapping met succes is ingesteld, zou u een antwoord moeten krijgen zoals hieronder weergegeven:
Samen met JUnit-tests als JUnit-regelconfiguratie
Wiremock-server kan worden gebruikt met JUnit-tests als een JUnit-regelopstelling. Hiermee zorgt JUnit voor de levenscyclus van Wiremock, d.w.z. Wiremock start en stopt.
vind commando in unix met voorbeelden
Het wordt meestal gebruikt in opstellingen waar u de server na elke test wilt starten en stoppen.
Dit heeft zijn eigen voordelen omdat het geïsoleerd is en een hoge mate van configureerbaarheid heeft in tegenstelling tot een stand-alone opstelling waarbij meerdere mensen uiteindelijk dezelfde server kunnen gebruiken en over elkaars stompe reacties kunnen stappen.
Laten we eens kijken naar een werkend voorbeeld van deze aanpak:
# 1) Maak een JUnit-regel voor de Wiremock-server. Deze stap is in wezen als een testconfiguratiestap waarbij we de JUnit-runner vertellen om de Wiremock-server voor elke test te instantiëren en de server na elke test te stoppen.
Dit betekent ook dat JUnit runner zorgt voor het starten en stoppen van de Wiremock-server, zonder dit expliciet te doen.
#twee) Nu gaan we onze test schrijven waarin we eerst onze client maken (met okHttp) om verzoeken uit te voeren tegen het gewenste eindpunt.
# 3) Maar u kunt hier opmerken dat we nog steeds geen stub hebben ingesteld die moet worden geretourneerd voor onze Wiremock-instantie. d.w.z. de bovenstaande client zal een URL http: // localhost: 8080 / test / abc aanvragen die geen geconfigureerde stub heeft. In dit geval retourneert de Wiremock-server een 404 zonder inhoud.
# 4) Om nu een stub in te stellen voor de bovenstaande URL voor onze Wiremock-serverinstantie, moeten we de statische methoden van de Wiremock-stub aanroepen, zoals hieronder wordt weergegeven.
Hier kun je zien dat we een aantal statische methoden hebben gebruikt, zoals configureFor, stubFor, enz. Al deze methoden maken deel uit van de Wiremock Java-bibliotheek. (We zullen deze methoden in detail bekijken in onze volgende tutorial / secties)
# 5) Nu de configuratiestap is voltooid, kunnen we het verzoek eenvoudig via de client uitvoeren en het antwoord valideren (afhankelijk van wat er is geconfigureerd voor de stub om terug te keren via Wiremock)
Samenvattend, hier is hoe het volledige codevoorbeeld eruit zou zien:
Afhankelijkheden vereist
Het is verkrijgbaar in:
- Een zelfstandige JAR die alleen de Wiremock-afhankelijkheid bevat.
- Een dikke pot met Wiremock en al zijn afhankelijkheden.
Beide smaken zijn beschikbaar als afhankelijkheden van Gradle en Maven. Meer details zijn beschikbaar in de officiële Maven-repository hier
Video-zelfstudie: Wiremock met JUnit-test
Gevolgtrekking
In deze tutorial hebben we de basisfuncties van Wiremock doorlopen en gezien hoe het kan worden uitgevoerd als een zelfstandige server en als onderdeel van de JUnit-tests met behulp van JUnit-regels.
We hebben ook kort ingegaan op stubbing en we zullen het in onze volgende tutorial in detail behandelen.
VOLGENDE zelfstudie
Aanbevolen literatuur
- Inleiding tot Micro Focus LoadRunner - Load Testing met LoadRunner Tutorial # 1
- Ngrok-zelfstudie: een korte introductie met installatie en configuratie
- TestNG-zelfstudie: inleiding tot TestNG-framework
- Inleiding tot Selenium WebDriver - Selenium Tutorial # 8
- Inleiding tot de programmeertaal van Java - videozelfstudie
- Python introductie en installatieproces
- Wat is Unix: een korte inleiding tot Unix
- Neoload-zelfstudie: introductie, download en installatie van Neoload