hieman taustaa
nykyään CI putkistot ovat välttämättömiä meidän kehityspäivätyö, auttaa meitä lyhentämään toimitusjaksoja ja tuoda laadukkaampia ohjelmistoja.
taustajärjestelmien kehittäjänä sovellusliittymistä on tullut cornestone useimmissa sovelluksissani, joten niiden testaamisesta tuli pakollista.
API-testausvaihe SISÄKORVAISTUTUSPUTKISTOSSA tuo meille luottamusta tuotteen laatuun ja hälyttää, jos jotain on mennyt rikki.
Postman
Postman on loistava työkalu, joka auttaa kehittäjiä API-elinkaaremme jokaisessa vaiheessa. Se on suuri dokumentaatio ja yhä yhteisö kehittäjät, jotka käyttävät sitä, joten se on helppo löytää virkaa selittää hienoja vinkkejä ja temppuja.
kokoelmat
postinkantajan on helppo järjestää erilaisia pyyntöjä kokoelmiksi. Itse luon kokoelman jokaista testattavaa projektia varten. Sitten, kokoelman sisällä, luon kansion jokaiselle entiteetille projektissa, yrittäen kattaa jokaisen päätepisteen API: ssa.
ympäristöt
Postman mahdollistaa erilaisten ympäristöjen luomisen pyyntöjemme ajamiseen. Annan todellisen esimerkin ja kerron työstäväni kolmea eri ympäristöä: paikallista ympäristöäni, lavastusympäristöä ja tuotantoympäristöä, joten luon kolme erilaista ympäristöä muuttujilla, jotka edustavat muuttuvaa dataa ympäristöjen välillä (kuten API-pyyntöjen pohjapolku). Näin voin määritellä yhden pyynnön, mutta kohdistaa sen kolmeen eri ympäristööni helposti. Mieti, kuinka helppoa olisi muuttaa tai lisätä uusi ympäristö!
Testauspyynnöt
yksi Postmanin suurimmista ominaisuuksista on se, että voit koodata testejä, jotka suoritetaan aina, kun pyyntö suoritetaan. Ne on kirjoitettu JS ja on viileä joukko väitteitä tarkistaa asioita, kuten vastaus koodi, vastaus elin o vastaus otsikot.
siistiä! Kun olemme kirjoittaneet testisarjan API: n kattamiseksi, käytämme Collection Runneria, Postmanin tarjoamaa sisäänrakennettua työkalua, joka suorittaa jokaisen keräyspyynnön ja tuottaa testituloksista raportin.
Bonus: Joskus haluamme ajaa pyyntömme tietyssä järjestyksessä ja arvaa mitä? Postinkantaja antaa meidän tehdä sen! Tarkista se osoitteesta building workflows issue
What do we have so far?
tässä vaiheessa olemme rakentaneet postinkantajien kokoelman, jossa on joukko pyyntöjä, jotka voisivat kohdistua API: Hamme kaikissa ympäristöissämme. Sen lisäksi jokaisessa pyynnössä on useita testejä, joilla tarkistetaan, toimiiko se oikein. Mikä aika olla elossa!
Newman
Muistatko aiemmin mainitsemani keräilijän? Se voisi suorittaa jokaisen pyynnön kokoelmassamme yksinkertaisella napsautuksella. Mutta entä komentorivityökalu tehdä sama? Newman tekee sen. Newman on Postmanin Komentorivikokoelma, jonka avulla voit suorittaa ja testata Postman-kokoelmaa suoraan komentoriviltä ja integroida sen helposti CI-palvelimiin, mikä tekee siitä erinomaisen työkalun tarkoitukseemme: automatisoida API-testimme Jenkinsin kanssa.
Run a collection
to run a collection with Newman, we first have to export it from Postman. Koska meillä on joitakin muuttujia pelissä joissakin pyynnöstämme, meidän on vietävä sopiva ympäristö liian. Kun meillä on molemmat tiedostot, voimme suorittaa kokoelman kanssa:
$ newman run our.postman_collection.json -e our.postman_environment.json
ja näemme raportin keräys ajaa, samanlainen kuin muut testaus puitteet.
tulosteen formatointi
raportti voidaan muotoilla eri tavoin. Tämän saavuttamiseksi Newman tarjoaa joukon toimittajia tukemaan eri tulostusmuotoja, kuten JSON, XUNIT tai HTML. Sen lisäksi, että voit luoda oman reportteri muotoilla raportin missä tahansa muodossa haluat.
Jenkins
Cool, olemme määritelleet API-testisarjamme Postmanin kanssa ja voimme ajaa sen komentoriviltä ja saada mukavan raportin tähänastisista tuloksista Newmanin kanssa. Mutta nyt haluamme sisällyttää uuden taitomme TIEDONANTAJAJÄRJESTELMÄÄMME.
Vastuuvapauslauseke: käytämme Jenkinsiä automaatiopalvelimena CI/CD-putkistojen rakentamiseen ja suoritamme CI-putkemme Telakkasäiliössä, johon on asennettu kaikki tarvittavat työkalut (kuten Newman).
Mixing things up
pohjimmiltaan tarvitsemme kolme tiedostoa sisällyttääksemme API-testimme CI-putken sisään:
- Jenkinsfile, joka määrittelee putkemme
- Postman Collection, joka määrittelee pyyntömme ja testimme
- Postman Environment, joka määrittelee kohdeympäristön muuttujat
sisällytämme ne kaikki projektivarastoon, jotta voimme hyötyä versiohallinnasta niiden suhteen ja seurata niiden muutoksia.
riittää puhuminen, koodataan!
meidän on luotava uusi vaihe putkeen API-testin suorittamiseksi. Laitamme sen yleensä yksikkö-ja integraatiotestien jälkeen varmistaaksemme, että kaikki toimii odotetusti ennen käyttöliittymän testausta.
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() } } ...}
kuten näette, käytämme Newmanin ajo-komentoa, – tarjoten kokoelmallemme testiympäristötiedoston parametreina. Sen lisäksi ilmoitamme myös, mitä toimittajia haluamme käyttää (JUNIT, HTML) ja mihin lähdöt tallennetaan.
bonuksena käytämme HTML PUblisher Jenkins-lisäosaa HTML-raportin linkittämiseen rakennukseen.
toivottavasti nautit tästä matkasta yhtä paljon kuin sitä kirjoittaessani ja kuten aina, palaute otetaan vastaan!