een beetje achtergrond
tegenwoordig zijn CI-pijpleidingen een must op onze ontwikkeling dayjob, die ons helpen om de leveringscycli te verkorten en software van hogere kwaliteit te leveren.
als backend-Ontwikkelaar zijn API ‘ s een cornestone geworden op de meeste van mijn applicaties, dus het testen ervan werd een must.
een API-testfase in onze CI-pijplijn geeft ons vertrouwen in de kwaliteit van het product en waarschuwt ons als er iets is gebroken.
Postman
Postman is een geweldige tool die ontwikkelaars helpt in elke fase van onze API-levenscyclus. Het heeft een geweldige documentatie en een steeds meer gemeenschap van ontwikkelaars die het gebruiken, dus het is gemakkelijk om berichten uit te leggen coole tips en trucs te vinden.
collecties
Postman maakt het gemakkelijk om onze verschillende verzoeken in collecties in te delen. Persoonlijk maak ik een collectie voor elk project dat ik wil testen. Dan, in de collectie, maak ik een map voor elke entiteit op het project, proberen om elk eindpunt in de API te dekken.
omgevingen
Postman stelt ons in staat om verschillende omgevingen te creëren om onze verzoeken uit te voeren. Om een echt voorbeeld te geven, zou ik je vertellen dat ik werk op drie verschillende omgevingen: mijn lokale omgeving, een staging omgeving en een productie omgeving, dus ik maak drie verschillende omgevingen met variabelen die de veranderende gegevens tussen de omgevingen representeert (zoals het basispad voor de API-verzoeken). Op deze manier kan ik een enkel verzoek definiëren, maar het gemakkelijk richten op mijn drie verschillende omgevingen. Denk na over hoe gemakkelijk zou zijn om een nieuwe omgeving te veranderen of toe te voegen!
Testaanvragen
een van de grootste functies van Postman is dat u tests kunt coderen die elke keer worden uitgevoerd als een verzoek wordt uitgevoerd. Ze zijn geschreven in JS en hebben een coole set van beweringen om dingen te controleren zoals de response code, response body o response headers.
gaaf! Zodra we een test suite hebben geschreven om onze API te dekken, gebruiken we de Collection Runner, een ingebouwde tool die door Postman wordt geleverd om elk verzoek van een collectie uit te voeren en een rapport van testresultaten uit te voeren.
Bonus: Soms willen we onze verzoeken in een bepaalde volgorde uitvoeren en raad eens? Postbode staat ons toe om het te doen! Controleer het bij building workflows issue
wat hebben we tot nu toe?
op dit moment hebben we een Postman collectie opgebouwd met een hoop verzoeken die onze API in al onze omgevingen kunnen richten. Daarnaast heeft elk verzoek verschillende tests om te controleren of het goed werkt. Wat een tijd om te leven!
Newman
herinnert u zich de verzamelaar die ik eerder noemde? Het kan elk verzoek in onze collectie draaien met een simpele klik. Maar hoe zit het met een command line tool om hetzelfde te doen? Newman doet het. Newman is een command line collectie Runner voor Postman die u toelaat om te draaien en testen van een Postman collectie direct vanaf de command line en gemakkelijk te integreren in CI servers, dat maakt het een geweldig hulpmiddel voor ons doel: automatiseren van onze API-test met Jenkins.
Run een collectie
om een collectie met Newman te draaien, moeten we deze eerst exporteren vanuit Postman. Omdat we een aantal variabelen spelen rond in een aantal van onze aanvraag, moeten we de geschikte omgeving te exporteren. Zodra we beide bestanden hebben, zijn we in staat om de collectie uit te voeren met:
$ newman run our.postman_collection.json -e our.postman_environment.json
en we zullen een rapport zien van de collection run, vergelijkbaar met andere test frameworks.
formatteren van de uitvoer
het rapport kan op verschillende manieren worden geformatteerd. Om dit te bereiken, biedt Newman een set verslaggevers aan om verschillende uitvoerformaten zoals JSON, XUNIT of HTML te ondersteunen. Daarnaast kunt u uw eigen reporter maken om het rapport in elk gewenst formaat te formatteren.
Jenkins
Cool, we hebben onze API test suite gedefinieerd met Postman en we zijn in staat om het uit te voeren vanaf de commandoregel en het verkrijgen van een mooi rapport van de resultaten tot nu toe met Newman. Maar nu willen we onze geweldige nieuwe vaardigheid opnemen in onze CI pijplijn.
Disclaimer: We gebruiken Jenkins als automatiseringsserver om onze CI/CD-pijpleidingen op te bouwen en we draaien onze CI-pijpleiding in een Docker-container waarin alle benodigde gereedschappen zijn geïnstalleerd (zoals Newman).
door elkaar halen
in wezen hebben we drie bestanden nodig om onze API-Test in een CI-pijplijn op te nemen:
- Jenkinsfile, dat onze pijplijn
- Postman collectie definieert, die onze set van aanvragen en tests definieert
- Postman omgeving, die de variabelen van de doelomgeving
definieert we nemen ze allemaal op in project repository, zodat we kunnen profiteren van versiebeheer over hen en hun wijzigingen volgen.
genoeg gepraat, laten we code!
we moeten een nieuwe fase in onze pijplijn maken om de API-Test uit te voeren. We zetten het meestal na unit-en integratietests om er zeker van te zijn dat alles draait zoals verwacht voordat de interface wordt getest.
pipeline { ... stage('Test API Rest') { steps { sh 'newman run tests/Newman/our.postman_collection.json -e tests/Newman/env/test.postman_environment.json -r junit,html --reporter-junit-export var/reports/newman/junit/newman.xml --reporter-html-export var/reports/newman/html/index.html' publishHTML() } } ...}
zoals u kunt zien, roepen we het run commando van Newman, het verstrekken van onze collectie een de test omgeving bestand als parameters. Daarnaast informeren we ook welke reporters we willen gebruiken (JUNIT, HTML) en waar de uitgangen worden opgeslagen.
als bonus gebruiken we HTML PUblisher Jenkins plugin om het HTML-rapport te koppelen aan de build.
ik hoop dat u net zo genoten hebt van deze reis als ik het schreef en, zoals altijd, feedback zal worden verwelkomd!