Automatizza i tuoi test API con Jenkins, Postman e Newman

Un po ‘ di background

Al giorno d’oggi le pipeline CI sono un must nel nostro lavoro di sviluppo, aiutandoci a ridurre i cicli di consegna e a portare software di qualità superiore.

Come sviluppatore di back-end, le API sono diventate una pietra miliare sulla maggior parte delle mie applicazioni, quindi testarle è diventato un must.

Avere una fase di test API nella nostra pipeline CI ci porta fiducia nella qualità del prodotto e ci avvisa se qualcosa si è rotto.

Postman

Postman è un ottimo strumento che aiuta gli sviluppatori in ogni fase del nostro ciclo di vita API. Ha una grande documentazione e una sempre più comunità di sviluppatori che lo utilizzano, quindi è facile trovare post che spiegano suggerimenti e trucchi interessanti.

Collezioni

Postman rende facile organizzare le nostre diverse richieste in collezioni. Personalmente creo una collezione per ogni progetto che voglio testare. Quindi, all’interno della raccolta, creo una cartella per ogni entità sul progetto, cercando di coprire ogni endpoint nell’API.

Ambienti

Postman ci consente di creare ambienti diversi per eseguire le nostre richieste. Dando un esempio reale, ti direi che lavoro su tre diversi ambienti: il mio ambiente locale, un ambiente di staging e un ambiente di produzione, quindi creo tre diversi ambienti con variabili che rappresentano i dati che cambiano tra gli ambienti (come il percorso di base per le richieste API). In questo modo posso definire una singola richiesta ma indirizzarla facilmente ai miei tre diversi ambienti. Pensa a quanto sarebbe facile cambiare o aggiungere un nuovo ambiente!

Prove richieste

Una delle caratteristiche principali del Postino è che consente di codice di test che viene eseguito ogni volta che una richiesta di esecuzione. Sono scritti in JS e hanno un bel set di asserzioni per controllare cose come il codice di risposta, il corpo di risposta o le intestazioni di risposta.

Dolce! Una volta che abbiamo scritto una suite di test per coprire la nostra API, usiamo il Collection Runner, uno strumento integrato fornito da Postman per eseguire ogni richiesta di una raccolta e produrre un rapporto dei risultati dei test.

Bonus: A volte, vogliamo eseguire le nostre richieste in un certo ordine e indovinate un po’? Postino ci permette di farlo! Controllalo al problema dei flussi di lavoro di costruzione

Cosa abbiamo finora?

A questo punto, abbiamo creato una collezione Postman con un sacco di richieste che potrebbero indirizzare la nostra API in tutti i nostri ambienti. Oltre a ciò, ogni richiesta ha diversi test per verificare se funziona correttamente. Che tempo per essere vivi!

Newman

Ti ricordi la Collezione Runner che ho citato in precedenza? Si potrebbe eseguire ogni richiesta nella nostra collezione con un semplice click. Ma che dire di uno strumento da riga di comando per fare lo stesso? Newman lo fa. Newman è un runner di raccolta da riga di comando per Postman che consente di eseguire e testare una raccolta Postman direttamente dalla riga di comando e integrarla facilmente nei server CI, il che lo rende un ottimo strumento per il nostro scopo: automatizzare il nostro test API con Jenkins.

Esegui una raccolta

Per eseguire una raccolta con Newman, dobbiamo prima esportarla da Postman. Poiché abbiamo alcune variabili che giocano in alcune delle nostre richieste, dobbiamo esportare anche l’ambiente adatto. Una volta che abbiamo entrambi i file, siamo in grado di eseguire la raccolta con:

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

e vedremo un rapporto dell’esecuzione della raccolta, simile ad altri framework di test.

Formattazione dell’output

Il report può essere formattato in diversi modi. Per raggiungere questo obiettivo, Newman fornisce una serie di reporter per supportare diversi formati di output come JSON, XUNIT o HTML. Oltre a ciò è possibile creare il proprio reporter per formattare il report in qualsiasi formato desiderato.

Jenkins

Fresco, abbiamo definito la nostra suite di test API con Postman e siamo in grado di eseguirlo da riga di comando e ottenere un bel rapporto dei risultati finora con Newman. Ma ora vogliamo includere la nostra fantastica nuova abilità nella nostra pipeline di CI.

Disclaimer: Stiamo usando Jenkins come server di automazione per costruire le nostre pipeline CI/CD e eseguiamo la nostra pipeline CI in un contenitore Docker con tutti gli strumenti necessari installati (come Newman).

Mescolare le cose

Essenzialmente avremo bisogno di tre file per includere il nostro test API all’interno di una pipeline CI:

• Jenkinsfile, che definisce la nostra pipeline
• Postman Collection, che definisce il nostro set di richieste e test
• Postman Environment, che definisce le variabili dell’ambiente di destinazione

Li includiamo tutti nel repository del progetto, in modo da poter beneficiare del controllo della versione su di loro e tenere traccia delle loro modifiche.

Basta parlare, codifichiamo!

Dobbiamo creare una nuova fase nella nostra pipeline per eseguire il test API. Di solito lo mettiamo dopo i test di unità e integrazione per essere sicuri che tutto funzioni come previsto prima di testare l’interfaccia.

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

Come puoi vedere, invochiamo il comando run di Newman, fornendo alla nostra collezione un file dell’ambiente di test come parametri. Oltre a ciò, informiamo anche quali reporter vogliamo usare (JUNIT, HTML) e dove verranno memorizzati gli output.

Come bonus, utilizziamo il plugin HTML PUblisher Jenkins per collegare il report HTML alla build.

Spero che questo viaggio ti sia piaciuto tanto quanto lo ho scritto io e, come sempre, i feedback saranno i benvenuti!