En liten bakgrunn
I Dag ER ci-rørledninger et must på vår utviklingsdagjobb, og hjelper oss med å forkorte leveringssykluser og å bringe programvare av høyere kvalitet.
Som backend-utvikler har Apier blitt en cornestone på de fleste av mine applikasjoner, så testing av dem ble et must.
Å Ha ET API-Teststadium i VÅR CI-rørledning gir oss tillit til kvaliteten på produktet og varsler oss om noe hadde brutt.
Postbud
Postbud er et flott verktøy som hjelper utviklere i alle faser av VÅR API livssyklus. Den har en god dokumentasjon og et stadig mer fellesskap av utviklere som bruker det, så det er lett å finne innlegg som forklarer kule tips og triks.
Samlinger
Postman gjør det enkelt å organisere våre ulike forespørsler i samlinger. Personlig lager jeg en samling for hvert prosjekt jeg vil teste. Så, inne i samlingen, lager jeg en mappe for hver enhet på prosjektet, og prøver å dekke hvert endepunkt I API.
Miljøer
Postman lar Oss lage forskjellige miljøer for å kjøre våre forespørsler. Å gi et reelt eksempel, jeg vil fortelle deg at jeg jobber med tre forskjellige miljøer: mitt lokale miljø, et staging miljø og et produksjonsmiljø, så jeg lager tre forskjellige miljøer med variabler som representerer de skiftende dataene mellom miljøene (som basisbanen for API-forespørslene). På denne måten kan jeg definere en enkelt forespørsel, men målrett den til mine tre forskjellige miljøer enkelt. Tenk på hvor lett det ville være å endre eller legge til et nytt miljø!
Testforespørsler
En Av De største funksjonene I Postman er at du kan kode tester som kjører hver gang en forespørsel kjøres. De er skrevet I JS og har et kult sett med påstander for å sjekke ting som svarkoden, response body o responshoder.
Søtt! Når Vi har skrevet en testpakke for å dekke VÅR API, bruker Vi Collection Runner, et innebygd verktøy levert Av Postman for å kjøre hver forespørsel om en samling og sende ut en rapport over testresultater.
Bonus: Noen ganger vil vi kjøre våre forespørsler i en bestemt rekkefølge og gjett hva? Postman tillater oss å gjøre det! Sjekk det på building workflows issue
Hva har vi så langt?
På dette punktet har vi bygget Opp En Postman-samling med en rekke forespørsler som kan målrette VÅR API i alle våre miljøer. Dessuten har hver forespørsel flere tester for å sjekke om den fungerer som den skal. For en tid å være i live!
Newman
husker Du Kolleksjonsløperen jeg nevnte tidligere? Det kan kjøre hver forespørsel i vår samling med et enkelt klikk. Men hva med et kommandolinjeverktøy for å gjøre det samme? Newman gjør det. Newman er en kommandolinje Samling Runner For Postman som lar Deg kjøre og teste En Postmann Samling direkte fra kommandolinjen og integrere det enkelt I CI servere, som gjør Det til et flott verktøy for vårt formål: Automatisere VÅR API test Med Jenkins.
Kjør en samling
for å kjøre en samling Med Newman må Vi først eksportere Den Fra Postman. Siden vi har noen variabler som spiller rundt i noen av våre forespørsler, må vi også eksportere det passende miljøet. Når vi har begge filene, kan vi kjøre samlingen med:
$ newman run our.postman_collection.json -e our.postman_environment.json
og vi vil se en rapport av samlingen kjøre, ligner på andre testing rammer.
Formatering av utdataene
rapporten kan formateres på forskjellige måter. For å oppnå Dette, Gir Newman et sett med journalister for å støtte ulike formater SOM JSON, XUNIT eller HTML. Dessuten kan du lage din egen reporter å formatere rapporten i alle formater du ønsker.
Jenkins
Kult, Vi har definert VÅR API test suite Med Postman, og vi kan kjøre Den fra kommandolinjen og få en fin rapport av resultatene så langt Med Newman. Men nå ønsker vi å inkludere vår fantastiske nye ferdighet i VÅR CI-rørledning.
Ansvarsfraskrivelse: Vi bruker Jenkins som automatiseringsserver for å bygge opp VÅRE ci / CD-rørledninger, og vi kjører VÅR ci-rørledning i En Docker-beholder som har alle nødvendige verktøy installert (For Eksempel Newman).
Blande ting opp
I Hovedsak trenger Vi tre filer for å inkludere VÅR API-Test inne i EN ci-rørledning:
- Jenkinsfile, som definerer vår pipeline
- Postmann Collection, som definerer vårt sett med forespørsel og tester
- Postmann Miljø, som definerer variablene i målmiljøet
vi inkluderer alle dem i prosjektarkiv, slik at vi kan dra nytte av versjonskontroll over dem og spore endringene deres.
nok snakk, la oss kode!
Vi må opprette en ny fase i vår pipeline for å kjøre API-Testen. Vi legger vanligvis det etter enhet og integrasjonstester for å være sikker på at alt kjører som forventet før du tester grensesnittet.
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åberoper Vi Kjørekommandoen Til Newman, og gir vår samling en testmiljøfilen som parametere. Dessuten informerer vi også hvilke journalister vi vil bruke (JUNIT, HTML) og hvor utgangene skal lagres.
som en bonus bruker VI HTML PUblisher Jenkins plugin for å koble HTML-rapporten til bygningen.
jeg håper du likte denne reisen så mye som jeg skrev det, og som alltid vil tilbakemelding bli ønsket velkommen!