Automatizarea testelor API cu Jenkins, poștaș și Newman

un pic de fundal

in zilele noastre conducte CI sunt o necesitate pe dayjob nostru de dezvoltare, ajutându-ne pentru a scurta cicluri de livrare și de a aduce software-ul de calitate superioară.

ca dezvoltator de backend, API-urile au devenit un cornestone pe majoritatea aplicațiilor mele, astfel încât testarea lor a devenit o necesitate.

a avea o etapă de testare API în conducta noastră CI ne aduce încredere în calitatea produsului și ne avertizează dacă s-a rupt ceva.

Poștaș

Poștaș este un instrument excelent care ajută dezvoltatorii în fiecare etapă a ciclului nostru de viață API. Are o documentație excelentă și o comunitate din ce în ce mai mare de dezvoltatori care o folosesc, așa că este ușor să găsești postări care explică sfaturi și trucuri interesante.

colecții

Poștașul face ușor de a organiza cererea noastră diferite în colecții. Personal creez o colecție pentru fiecare proiect pe care vreau să îl testez. Apoi, în interiorul colecției, creez un folder pentru fiecare entitate din proiect, încercând să acopăr fiecare punct final din API.

medii

Poștaș ne permite să creăm medii diferite pentru a rula cererile noastre. Dând un exemplu real, v-aș spune că lucrez în trei medii diferite: mediul meu local, un mediu de așteptare și un mediu de producție, așa că creez trei medii diferite cu variabile care reprezintă schimbarea datelor între medii (cum ar fi calea de bază pentru cererile API). În acest fel, pot defini o singură cerere, dar o pot viza cu ușurință în cele trei medii diferite. Gândiți-vă cât de ușor ar fi să schimbați sau să adăugați un mediu nou!

testarea cererilor

una dintre cele mai mari caracteristici ale Postman este că vă permite să Cod teste care se execută de fiecare dată când o cerere a alerga. Acestea sunt scrise în JS și au un set rece de afirmații pentru a verifica lucruri cum ar fi codul de răspuns, corpul de răspuns o anteturile de răspuns.

dulce! Odată ce am scris o suită de testare pentru a acoperi API-ul nostru, vom folosi Collection Runner, un instrument încorporat furnizat de poștaș pentru a rula fiecare cerere de o colecție și de ieșire un raport al rezultatelor testelor.

Bonus: Uneori, vrem să ruleze cererile noastre într-o anumită ordine și ghici ce? Poștașul ne permite să o facem! Verificați-l la construirea fluxurilor de lucru problema

ce avem până acum?

în acest moment, am construit o colecție de poștași cu o grămadă de cereri care ar putea viza API-ul nostru în toate mediile noastre. În plus, fiecare cerere are mai multe teste pentru a verifica dacă funcționează corect. Ce timp pentru a fi în viață!

Newman

îți amintești de colecția Runner pe care am menționat-o anterior? Ar putea rula fiecare cerere din colecția noastră cu un simplu clic. Dar ce zici de un instrument de linie de comandă pentru a face același lucru? Newman o face. Newman este un alergător de colectare a liniei de comandă pentru poștaș care vă permite să rulați și să testați o colecție Poștaș direct din linia de comandă și să o integrați cu ușurință în serverele CI, ceea ce îl face un instrument excelent pentru scopul nostru: Automatizați testul nostru API cu Jenkins.

rulați o colecție

pentru a rula o colecție cu Newman, trebuie mai întâi să o exportăm de la poștaș. Deoarece avem unele variabile care se joacă în unele dintre cererile noastre, trebuie să exportăm și mediul adecvat. Odată ce avem ambele fișiere, putem rula colecția cu:

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

și vom vedea un raport al rulării colecției, similar cu altele cadre de testare.

formatarea ieșirii

raportul poate fi formatat în moduri diferite. Pentru a realiza acest lucru, Newman oferă un set de reporteri pentru a sprijini diferite formate de ieșire, cum ar fi JSON, xUnit sau HTML. În afară de faptul că puteți crea propriul reporter pentru a formata raportul în orice format doriți.

Jenkins

Cool, am definit suita noastră de testare API cu poștaș și suntem capabili să-l ruleze de la linia de comandă și de a obține un raport frumos a rezultatelor până în prezent cu Newman. Dar acum vrem să includem noua noastră abilitate minunată în conducta noastră CI.

Disclaimer: folosim Jenkins ca server de automatizare pentru a construi conductele noastre CI/CD și rulăm conducta CI într-un container Docker care are toate instrumentele necesare instalate (cum ar fi Newman).

amestecarea lucrurilor

în esență, vom avea nevoie de trei fișiere pentru a include testul nostru API în interiorul unei conducte CI:

• Jenkinsfile, care definește conducta noastră
• colecția poștaș, care definește setul nostru de cereri și teste
• mediul poștaș, care definește variabilele mediului țintă

le includem pe toate în depozitul de proiecte, astfel încât să putem beneficia de controlul versiunii asupra lor și să urmărim modificările lor.

destul de vorbit, hai să codăm!

trebuie să creăm o nouă etapă în conducta noastră pentru a rula testul API. De obicei, îl punem după testele de unitate și integrare pentru a fi siguri că totul funcționează așa cum era de așteptat înainte de a testa interfața.

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

după cum puteți vedea, invocăm comanda run a lui Newman, oferind colecției noastre un fișier de mediu de testare ca parametri. În plus, informăm și ce reporteri dorim să folosim (JUNIT, HTML) și unde vor fi stocate ieșirile.

ca bonus, folosim pluginul HTML PUblisher Jenkins pentru a lega raportul HTML la construire.

sper că v-a plăcut această călătorie la fel de mult cum am scris-o și, ca întotdeauna, feedback-ul va fi binevenit!