en liten bakgrund
numera CI pipelines är ett måste på vår utveckling dayjob, hjälper oss att förkorta leveranscykler och att få högre kvalitet programvara.
som backend-utvecklare har API: er blivit en cornestone på de flesta av mina applikationer, så att testa dem blev ett måste.
att ha ett API-Teststadium i vår CI-pipeline ger oss förtroende för produktens kvalitet och varnar oss om något hade brutit.
Postman
Postman är ett bra verktyg som hjälper utvecklare i varje steg i vår API livscykel. Den har en bra dokumentation och en alltmer gemenskap av utvecklare som använder den, så det är lätt att hitta inlägg som förklarar coola tips och tricks.
Samlingar
Postman gör det enkelt att organisera vår olika begäran i samlingar. Personligen skapar jag en samling för varje projekt jag vill testa. Sedan, inuti samlingen, skapar jag en mapp för varje enhet på projektet, försöker täcka varje slutpunkt i API.
miljöer
Postman tillåter oss att skapa olika miljöer för att köra våra förfrågningar. Med ett riktigt exempel skulle jag säga att jag arbetar med tre olika miljöer: min lokala miljö, en staging-miljö och en produktionsmiljö, så jag skapar tre olika miljöer med variabler som representerar de förändrade data mellan miljöerna (som basvägen för API-förfrågningarna). På så sätt kan jag definiera en enda förfrågan men rikta den till mina tre olika miljöer enkelt. Tänk på hur lätt det skulle vara att ändra eller lägga till en ny miljö!
Testförfrågningar
en av de största funktionerna i Postman är att du kan koda tester som körs varje gång en begäran körs. De är skrivna i JS och har en cool uppsättning påståenden för att kontrollera saker som svarskoden, response body o response headers.
sött! När vi har skrivit en testsvit för att täcka vårt API använder vi Collection Runner, ett inbyggt verktyg som tillhandahålls av Postman för att köra varje begäran om en samling och mata ut en rapport om testresultat.
Bonus: Ibland vill vi köra våra förfrågningar i en viss ordning och gissa vad? Postman tillåter oss att göra det! Kolla in det på building workflows issue
Vad har vi hittills?
vid denna tidpunkt har vi byggt upp en Brevbärarsamling med en massa förfrågningar som kan rikta in vårt API i alla våra miljöer. Dessutom har varje begäran flera tester för att kontrollera om den fungerar korrekt. Vilken tid att leva!
Newman
kommer du ihåg Samlingslöparen jag nämnde tidigare? Det kan köra varje begäran i vår samling med ett enkelt klick. Men hur är det med ett kommandoradsverktyg för att göra detsamma? Newman gör det. Newman är en kommandoradssamlingslöpare för Postman som låter dig köra och testa en Postmansamling direkt från kommandoraden och integrera den enkelt i CI-servrar, vilket gör det till ett bra verktyg för vårt syfte: automatisera vårt API-test med Jenkins.
kör en samling
för att kunna köra en samling med Newman måste vi först exportera den från Postman. Eftersom vi har några variabler som spelar runt i en del av vår begäran, måste vi exportera lämplig miljö också. När vi har båda filerna kan vi köra samlingen med:
$ newman run our.postman_collection.json -e our.postman_environment.json
och vi kommer att se en rapport om insamlingskörningen, som liknar andra testramar.
formatera utdata
rapporten kan formateras på olika sätt. För att uppnå detta tillhandahåller Newman en uppsättning reportrar för att stödja olika utdataformat som JSON, XUNIT eller HTML. Dessutom kan du skapa din egen reporter för att formatera rapporten i vilket format du vill.
Jenkins
Cool, vi har definierat vår API-testsvit med Postman och vi kan köra den från kommandoraden och få en fin rapport om resultaten hittills med Newman. Men nu vill vi inkludera vår fantastiska nya skicklighet i vår ci-pipeline.
ansvarsfriskrivning: vi använder Jenkins som en automationsserver för att bygga upp våra CI/CD-rörledningar och vi kör vår CI-rörledning i en Docker-behållare som har alla nödvändiga verktyg installerade (såsom Newman).
blanda upp saker
i huvudsak behöver vi tre filer för att inkludera vårt API-Test i en CI-pipeline:
- Jenkinsfile, som definierar vår pipeline
- Postman Collection, som definierar vår uppsättning begäran och tester
- Postman Environment, som definierar variablerna i målmiljön
vi inkluderar dem alla i projektförvaret, så att vi kan dra nytta av versionskontroll över dem och spåra deras ändringar.
nog att prata, låt oss koda!
vi måste skapa ett nytt steg i vår pipeline för att köra API-testet. Vi lägger det vanligtvis efter enhets-och integrationstester för att vara säker på att allt körs som förväntat innan du testar gränssnittet.
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 åberopar vi körkommandot för Newman, vilket ger vår samling en testmiljöfil som parametrar. Förutom det informerar vi också vilka reportrar vi vill använda (JUNIT, HTML) och var utgångarna kommer att lagras.
som en bonus använder vi HTML PUblisher Jenkins plugin för att länka HTML-rapporten till byggnaden.
jag hoppas att du gillade den här resan lika mycket som jag skrev den och som alltid kommer feedback att välkomnas!