Automatiser dine API-test med Jenkins, postbud og Nymand

en lille baggrund

i dag er CI-rørledninger et must på vores udviklingsdagjob, hvilket hjælper os med at forkorte leveringscyklusser og bringe programmer af højere kvalitet.

som backend-udvikler er API ‘ er blevet en cornestone på de fleste af mine applikationer, så test af dem blev et must.

at have en API-testfase i vores CI-pipeline giver os tillid til produktets kvalitet og advarer os, hvis noget var brudt.

Postman

Postman er et fantastisk værktøj, der hjælper udviklere i alle faser af vores API livscyklus. Det har en stor dokumentation og et stadig mere fællesskab af udviklere, der bruger det, så det er nemt at finde indlæg, der forklarer seje tips og tricks.

samlinger

postbud gør det nemt at organisere vores forskellige anmodning i samlinger. Personligt opretter jeg en samling til hvert projekt, jeg vil teste. Derefter opretter jeg en mappe til hver enhed i projektet inde i samlingen og forsøger at dække hvert slutpunkt i API ‘ en.

miljøer

Postman giver os mulighed for at oprette forskellige miljøer til at køre vores anmodninger. Når jeg giver et reelt eksempel, vil jeg fortælle dig, at jeg arbejder på tre forskellige miljøer: mit lokale miljø, et iscenesættelsesmiljø og et produktionsmiljø, så jeg opretter tre forskellige miljøer med variabler, der repræsenterer de skiftende data mellem miljøerne (som basisstien for API-anmodninger). På denne måde kan jeg definere en enkelt anmodning, men målrette den let mod mine tre forskellige miljøer. Tænk på, hvor nemt det ville være at ændre eller tilføje et nyt miljø!

Testanmodninger

en af de største funktioner i Postman er, at det giver dig mulighed for at kode test, der kører hver gang en anmodning kører. De er skrevet i JS og har et køligt sæt påstande for at kontrollere ting som svarkoden, responskrop o responsoverskrifter.

sødt! Når vi har skrevet en testpakke til at dække vores API, bruger vi Collection Runner, et indbygget værktøj leveret af postbud til at køre enhver anmodning fra en samling og udsende en rapport med testresultater.

Bonus: Nogle gange vil vi køre vores anmodninger i en bestemt rækkefølge og gætte hvad? Postbud tillader os at gøre det! Tjek det på byggearbejdsgange problem

Hvad har vi hidtil?

på dette tidspunkt har vi opbygget en Postbudssamling med en masse anmodninger, der kunne målrette vores API i alle vores miljøer. Derudover har hver anmodning flere tests for at kontrollere, om den fungerer korrekt. Hvilken tid at være i live!

Nymand

kan du huske den Samlingsløber, jeg nævnte tidligere? Det kunne køre hver anmodning i vores samling med et enkelt klik. Men hvad med et kommandolinjeværktøj til at gøre det samme? Nymand gør det. Det giver dig mulighed for at køre og teste en Postbudssamling direkte fra kommandolinjen og integrere den let i CI-servere, hvilket gør det til et godt værktøj til vores formål: Automatiser vores API-test med Jenkins.

Kør en samling

for at køre en samling med Nymand skal vi først eksportere den fra Postmand. Da vi har nogle variabler, der spiller rundt i nogle af vores anmodninger, er vi også nødt til at eksportere det passende miljø. Når vi har begge filer, er vi i stand til at køre samlingen med:

$ newman run our.postman_collection.json -e our.postman_environment.json

og vi vil se en rapport om indsamlingskørslen, svarende til andre testrammer.

formatering af output

rapporten kan formateres på forskellige måder. For at opnå dette leverer vi et sæt journalister, der understøtter forskellige outputformater som f.eks. Derudover kan du oprette din egen reporter til at formatere rapporten i ethvert format, du ønsker.

Jenkins

Cool, vi har defineret vores API-testpakke med postbud, og vi er i stand til at køre den fra kommandolinjen og få en dejlig rapport om resultaterne hidtil med Nymand. Men nu vil vi medtage vores fantastiske nye færdigheder i vores CI-pipeline.

Ansvarsfraskrivelse: Vi bruger Jenkins som en automatiseringsserver til at opbygge vores CI/CD-rørledninger, og vi kører vores CI-rørledning i en Docker-container, der har alle de nødvendige værktøjer installeret (sådan Nymand).

blanding af ting

i det væsentlige har vi brug for tre filer for at inkludere vores API-Test inde i en CI-pipeline:

• Jenkinsfile, som definerer vores pipeline
• Postman Collection, som definerer vores sæt anmodning og test
• Postman Environment, som definerer variablerne i målmiljøet

vi inkluderer dem alle i project repository, så vi kan drage fordel af versionskontrol over dem og spore deres ændringer.

nok taler, lad os kode!

vi er nødt til at oprette en ny fase i vores pipeline for at køre API-testen. Vi sætter det normalt efter enheds-og integrationstest for at være sikker på, at alt kører som forventet, før vi tester grænsefladen.

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() } } ...}

som du kan se, påberåber vi os kommandoen Kør, hvilket giver vores samling en testmiljøfilen som parametre. Derudover informerer vi også, hvilke journalister vi vil bruge (JUNIT, HTML), og hvor output gemmes.

som en bonus bruger vi HTML PUblisher Jenkins plugin til at linke HTML-rapporten til build.

jeg håber du nød denne rejse så meget som jeg skrev det, og som altid vil feedback blive hilst velkommen!