Automatisez vos tests API avec Jenkins, Postman et Newman

Un peu de contexte

De nos jours, les pipelines CI sont un must dans notre travail de développement, nous aidant à raccourcir les cycles de livraison et à apporter des logiciels de meilleure qualité.

En tant que développeur backend, les API sont devenues une pierre angulaire sur la plupart de mes applications, donc les tester est devenu un must.

Avoir une étape de test d’API dans notre pipeline CI nous apporte confiance dans la qualité du produit et nous alerte si quelque chose s’est cassé.

Postman

Postman est un excellent outil qui aide les développeurs à chaque étape du cycle de vie de notre API. Il dispose d’une excellente documentation et d’une communauté de développeurs de plus en plus nombreuse qui l’utilisent, il est donc facile de trouver des articles expliquant des trucs et astuces sympas.

Collections

Postman facilite l’organisation de nos différentes demandes en collections. Personnellement, je crée une collection pour chaque projet que je veux tester. Ensuite, à l’intérieur de la collection, je crée un dossier pour chaque entité du projet, en essayant de couvrir tous les points de terminaison de l’API.

Environnements

Postman nous permet de créer différents environnements pour exécuter nos demandes. En donnant un exemple concret, je vous dirais que je travaille sur trois environnements différents: mon environnement local, un environnement de staging et un environnement de production, donc je crée trois environnements différents avec des variables qui représentent les données changeantes entre les environnements (comme le chemin de base pour les requêtes API). De cette façon, je peux définir une seule requête mais la cibler facilement sur mes trois environnements différents. Pensez à quel point il serait facile de changer ou d’ajouter un nouvel environnement!

Demandes de test

L’une des plus grandes fonctionnalités de Postman est qu’elle vous permet de coder des tests qui s’exécutent à chaque exécution d’une demande. Ils sont écrits en JS et ont un ensemble d’assertions sympas pour vérifier des choses comme le code de réponse, le corps de réponse o les en-têtes de réponse.

Doux! Une fois que nous avons écrit une suite de tests pour couvrir notre API, nous utilisons Collection Runner, un outil intégré fourni par Postman pour exécuter chaque demande d’une collection et produire un rapport des résultats des tests.

Bonus: Parfois, nous voulons exécuter nos demandes dans un certain ordre et deviner quoi? Le facteur nous permet de le faire! Vérifiez-le à la question des flux de travail de construction

Qu’avons-nous jusqu’à présent?

À ce stade, nous avons créé une collection Postman avec un tas de demandes qui pourraient cibler notre API dans tous nos environnements. En plus de cela, chaque demande a plusieurs tests pour vérifier si elle fonctionne correctement. Quel moment d’être en vie!

Newman

Vous souvenez-vous du Coureur de collection que j’ai mentionné précédemment? Il pourrait exécuter chaque demande de notre collection en un simple clic. Mais qu’en est-il d’un outil de ligne de commande pour faire de même? Newman le fait. Newman est un coureur de collection en ligne de commande pour Postman qui vous permet d’exécuter et de tester une collection de Postman directement à partir de la ligne de commande et de l’intégrer facilement dans les serveurs CI, ce qui en fait un excellent outil pour notre objectif: Automatiser notre test API avec Jenkins.

Exécuter une collection

Pour exécuter une collection avec Newman, nous devons d’abord l’exporter depuis Postman. Étant donné que certaines variables jouent dans certaines de nos demandes, nous devons également exporter l’environnement approprié. Une fois que nous avons les deux fichiers, nous pouvons exécuter la collection avec:

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

et nous verrons un rapport de l’exécution de la collection, similaire à d’autres frameworks de test.

Formatage de la sortie

Le rapport peut être formaté de différentes manières. Pour ce faire, Newman fournit un ensemble de reporters pour prendre en charge différents formats de sortie tels que JSON, XUNIT ou HTML. En outre, vous pouvez créer votre propre journaliste pour formater le rapport dans le format de votre choix.

Jenkins

Cool, nous avons défini notre suite de tests API avec Postman et nous sommes en mesure de l’exécuter à partir de la ligne de commande et d’obtenir un bon rapport des résultats jusqu’à présent avec Newman. Mais maintenant, nous voulons inclure notre nouvelle compétence impressionnante dans notre pipeline d’IC.

Avertissement: Nous utilisons Jenkins comme serveur d’automatisation pour construire nos pipelines CI / CD et nous exécutons notre pipeline CI dans un conteneur Docker sur lequel tous les outils nécessaires sont installés (tel Newman).

Mélanger les choses

Essentiellement, nous aurons besoin de trois fichiers pour inclure notre test API dans un pipeline CI:

• Jenkinsfile, qui définit notre pipeline
• Collection Postman, qui définit notre ensemble de requêtes et de tests
• Environnement Postman, qui définit les variables de l’environnement cible

Nous les incluons toutes dans le référentiel du projet, afin que nous puissions bénéficier d’un contrôle de version sur elles et suivre leurs modifications.

Assez parlé, codons!

Nous devons créer une nouvelle étape dans notre pipeline pour exécuter le test API. Nous le mettons généralement après les tests unitaires et d’intégration pour nous assurer que tout fonctionne comme prévu avant de tester l’interface.

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

Comme vous pouvez le voir, nous appelons la commande run de Newman, fournissant à notre collection un fichier d’environnement de test en tant que paramètres. En plus de cela, nous informons également les journalistes que nous voulons utiliser (JUNIT, HTML) et où les sorties seront stockées.

En bonus, nous utilisons le plugin Jenkins de l’éditeur HTML pour lier le rapport HTML à la construction.

J’espère que ce voyage vous a plu autant que je l’ai écrit et, comme toujours, les retours seront les bienvenus!