Publicat el dia 2 d’agost del 2016.
Què és l’automatització de proves?
L’automatització de proves consisteix a utilitzar un programa per controlar l’execució de proves i comprovar si els resultats obtinguts són els que estàvem esperant. Per explicar com aconseguir l’automatització de proves sobre una API es necessitaran tres programes: Postman, Newman i Jenkins.
Postman
El primer programa que utilitzarem per aconseguir l’automatització de proves és Postman que es pot definir de la següent manera:
“l’objectiu principal d’Postman és ajudar a construir APIs ràpidament permetent la àgil creació de peticions i fluxos de treball mitjançant col·leccions”
entorn
el primer que hem de fer abans de començar a crear tests és preparar un entorn per al servidor en el qual es van a executar els tests. per crear un entorn ens dirigim a Manage environments → Add . Llavors podrem començar a afegir parells clau-valor corresponents a variables que utilitzarem en múltiples ocasions en les peticions.
Com a exemple, he triat la següent API per explicar com funciona: swapi.co/api, així que anem a guardar-la en una variable a la qual anomenarem host:
Aquesta API no necessita que l’usuari s’autentiqui, però si ho necessités podríem guardar l’usuari i la contrasenya en l’entorn.
col·lecció
Postman permet crear col·leccions per emmagatzemar les peticions, de manera que el primer que necessitem és crear una col·lecció, proporcionant el seu nom (obligatori) i una descripció.
Llavors podrem crear una petició, que tindrà més o menys el següent aspecte:
En aquest exemple intentem aconseguir una llista de naus espacials, per la qual que a la captura de pantalla es pot observar:
- Nom de la petició.
- Mètode: pot ser GET, POST, PUT, DELETE …
- API: l’adreça completa seria swapi.co/api/starships, però com ja guardem swapi.co/api en la variable d’entorn host només hem d’escriure {{host} } Per usar-la.
- Entorn.
La segona part de la creació d’una petició és la secció Tests, pensada per crear asserts que verifiquin que la informació que retorna el servidor és la que estàvem esperant i també es poden assignar valors a noves variables d’entorn o globals per utilitzar més endavant. Per exemple:
En aquest test tenim un assert que comprova que el codi de estat és un 200 ia més, un bucle per emmagatzemar en una variable d’entorn informació sobre una determinada nau de totes les retornades. A la part dreta tenim una sèrie de trossos de codi que ajuden a l’usuari a la creació de tests.
El següent pas seria guardar la petició prement el botó “Save” i triar on guardar-la. Tenim l’opció de guardar-la directament a la col·lecció:
O en una carpeta. emmagatzemar-les en carpetes té l’avantatge de poder aïllar la seva execució d’la resta de peticions.
execució de Tests
Per executar la petició creada primer caldrà guardar-la (Important!) i després enviar-la fent clic a “Send”. De la resposta ens interessa dues parts: Body, on veiem el json retornat pel servidor amb tota la informació i Tests, on es veurà el resultat dels asserts.
en aquest cas un dels 2 tests va fallar perquè es va especificar en els tests que s’esperava rebre més de 100 naus i si observem la informació rebuda hi ha menys .
Un cop tenim totes les peticions que volem juntament amb els seus tests es poden executar en conjunt. Per això necessitem obrir el “Collection Runner”:
Per executar els tests hem seguir els següents passos:
- Escollir entre executar la col·lecció sencera o només una carpeta.
- Escollir l’entorn on tenim emmagatzemades les variables.
- Nombre de vegades que volem executar els tests.
- Start Test (Iniciar Test)
Un cop finalitza l’execució es poden veure els resultat a la part dreta de la pantalla. dalt de el tot apareixerà un resum en què es pot veure quants tests van fallar, quants no i quant van trigar a executar-se. A sota apareixerà el mateix, però per a cada petició realitzada.
Newman
Postman té una Versió de Línia de ordres anomenada Newman que té moltes utilitats però només ens cal una: Permet la integració de les col·leccions creades en Postman amb un sistema d’integració contínua com Jenkins, que és un pas clau per aconseguir l’automatització de proves.
Instal·lar Newman és molt fàcil:
Abans de començar a executar el test primer hem d’exportar l’entorn des Postman.
I la col·lecció:
Així guardarem un json de l’entorn i un altre de la col·lecció en una carpeta, a la qual haurem de dirigir-nos des d’una consola de comandaments per poder executar Newman .
Ara, podem triar entre executar la col·lecció completa:
O només una carpeta (afegintl’argument -f):
La sortida retorna gairebé el mateix que retornava la de Postman: L’execució de cada petició i un resum indicant quants tests van fallar i quants no.
Jenkins
l’últim pas per completar l’automatització de proves sobre l’API triada és instal·lar Newman en el mateix servidor en què està Jenkins i instal·lar uns connectors:
- Log Parser Plugin: Per analitzar sintàcticament la sortida.
- Configuració:
- Descripció: Error parsing.
- Parsing Rules File: Arxiu amb les regles i amb el següent contingut:
- Configuració:
- e-mail Extension Plugin: Per rebre un email si algun test falla.
Un cop tenim els connectors instal·lats i configurats vam crear un nou treball (New job) amb la següent informació:
Nom de el projecte: Star Wars (per exemple)
Build → Add build step → Execute Shell i escrivim la mateixa es rius d’ordres qui escrivíem per executar Newman en local:
Post-build Actions → Add post-build action → Console Output (build log) parsing
I a Select Parsing Rules seleccionem “Error Parsing” (Descripció)
post-build Actions → Add post-build action → Editable email Notification
I omplim la següent informació:
- Project Recipient List: Direccions de correu que han de rebre el correu electrònic.
- Advanced Settings → Add Trigger → Script – After Build
- Trigger Script :
Desa (Save) i Construir (Build now) …
La consola de sortida mostrarà el mateix que en executar Newman en local juntament amb algunes línies que indiquen que Jenkins ha fet els seus comprovacions.
He executat a propòsit la carpeta “Starships” perquè sé que un test va fallar i així provocar que enviï un correu electrònic. L’email rebut serà:
Hi podem observar que l’assumpte indica que alguna cosa no va ser ben (Something went wrong …) i en el cos de l’missatge que Jenkins va executar la feina correctament i un enllaç a la sortida de l’execució per veure els resultats.
Un cop estem a la consola de sortida de la feina podem accedir a “Parsed Console Output” per veure subratllades en vermell les línies en què apareixen els tests que van fallar.
Aconseguir automatització de proves sobre qualsevol API és tan fàcil com seguir els passos indicats en aquest post, només ens cal configurar tres programes i no haurem de preocupar-nos de res més. Ja s’encarregarà Jenkins d’enviar-nos un correu si va fallar algun test