Comment exécuter des tests de validation API dans votre pipeline de déploiement continu
Chaque année, de plus en plus d’entreprises de logiciels adoptent une architecture à microservices en utilisant des interfaces de programmation d’application (API), car les API facilitent l’accès des différentes équipes d’un projet aux ressources des autres. Les API permettent également aux entreprises de logiciels ou aux particuliers de récupérer des données les uns des autres : par exemple, Twitter dispose d’une API utilisée par de nombreuses petites entreprises pour récupérer les tweets relatifs à leur activité et les afficher sur la page web de leur entreprise.
Une autre grande caractéristique des API est qu’elles sont plus petites qu’une application monolithique, ce qui signifie qu’elles peuvent être déployées fréquemment. Dans l’entreprise où je travaille, chaque équipe possède plusieurs API, et nous avons huit environnements différents sur lesquels nous déployons. Si nous ne comptions que sur des tests manuels pour vérifier que les API avaient bien été déployées, nous devrions exécuter huit séries de tests pour chaque version d’API. Et si nous déployions plusieurs API en même temps, ce qui arrive souvent car nos API fonctionnent ensemble, nous pourrions avoir à exécuter des centaines de tests. Et en déployant toutes les deux semaines, ces tests représenteraient un grand nombre de vérifications fastidieuses et répétitives !
Nous avons résolu ce problème en configurant des tests automatisés d'API (smoke tests) qui s'exécutent à chaque déploiement, dans chaque environnement. Dans cet article, je vais expliquer comment nous avons décidé quoi tester et comment nous avons mis en place nos smoke tests. Nous avons utilisé Postman, Newman, Powershell et Octopus pour configurer nos tests automatisés, donc j’expliquerai ce que nous avons fait avec ces outils. Cependant, ces stratégies peuvent être adaptées à tout pipeline de déploiement continu (CD).
Première étape : déterminer quoi tester
L’objectif principal des smoke tests est d’effectuer quelques tests simples et de haut niveau afin de vérifier que le déploiement a été réalisé avec succès. Ce n’est pas l’endroit où il faut tester toutes les fonctionnalités de votre API. Voici ce que nous avons pris en compte pour concevoir nos smoke tests :
- Nous avons mis en place un test du « parcours heureux » pour chaque point d’accès (endpoint), c’est-à-dire un test censé fonctionner avec succès. Par exemple, une requête GET sur une ressource avec un identifiant précis est censée renvoyer cette ressource. Il convient de tester chaque point d’accès pour vérifier que tous fonctionnent comme prévu.
- Si un point d’accès pouvait être utilisé de différentes manières majeures, nous ajoutions un ou plusieurs tests pour vérifier ces variations. Par exemple, nous disposons d’une API de récupération de fichiers permettant d’obtenir un fichier via deux méthodes différentes. L’endpoint est le même, mais le contenu des requêtes diffère. Donc nous avons ajouté un test pour chaque méthode.
- Pour les points d’accès nécessitant un certain niveau de sécurité, nous avons ajouté un test afin de vérifier qu’une requête sans l’authentification appropriée ne renverrait PAS d’information, mais retournerait plutôt une erreur de type 400.
- Nous n’avons pas ajouté d’autres tests négatifs, comme une requête POST contenant des données hors des paramètres autorisés, car nous considérions qu’ils n’étaient pas nécessaires pour vérifier que l’API fonctionnait. Nous exécutons ces tests dans le cadre d’une suite de tests de régression nocturne.
Deuxième étape : exportez vos tests
Nous avons utilisé Postman pour créer nos tests d’API, de sorte que, lorsque les tests étaient créés, nous exportions à la fois la collection de tests et le fichier d’environnement de test au format JSON. Pour ceux qui ne connaissent pas Postman, un environnement de test est un ensemble de variables pouvant être référencées dans une collection de tests.
Troisième étape : écrivez un script pour exécuter vos tests
Postman dispose d’un outil en ligne de commande appelé Newman, qui permet d’exécuter une collection de tests. C’est donc ce que nous avons utilisé pour lancer nos tests. Nous avons créé un script Powershell qui exécute la commande Newman.
Quatrième étape : créez une étape de déploiement pour appeler votre script
Une fois le script Powershell prêt, nous avons ajouté une étape de déploiement dans chaque projet de déploiement API Octopus, afin d’exécuter le script de test. Si le script échouait, le déploiement échouait également.
Cinquième étape : organisez vos variables
Les variables sont souvent à prendre en compte lors de l’exécution de smoke tests dans différents environnements. Par exemple, dans votre environnement QA, l’identifiant de votre utilisateur de test peut être 340, alors que dans votre environnement de préproduction (Staging), cet identifiant peut être 620. Autre difficulté avec les variables : pour des raisons de sécurité, il se peut que vous n’ayez pas accès aux mots de passe ou aux clés dans les environnements de Production. C’était le cas pour notre équipe, mais heureusement Octopus possède les valeurs nécessaires pour exécuter nos tests en Production ; nous avons donc résolu le problème en faisant passer par Octopus les valeurs dont nous avions besoin dans notre script de test.
Il existait trois types différents de variables dont nous avions besoin pour nos smoke tests :
- Type 1 : Variables inchangées selon l’environnement de test, telles que “firstName” : “Prunella”. Ces variables pouvaient être placées directement dans l’environnement Postman, donc rien de plus n’était requis pour celles-ci.
- Type 2 : Variables qui changeaient selon l’environnement de test, mais qui n’avaient pas besoin d’être conservées de façon sécurisée, telles que “userId” : 340. Ces variables étaient ajoutées comme variables Octopus de cette manière : “smoke.userId”, et la valeur de la variable était définie pour chaque environnement : par exemple, QA était défini à 340, Staging à 620 et Production à 450.
- Type 3 : Variables qui changeaient pour chaque environnement de test et devaient rester sécurisées, comme « apiKey » : « b20628a9-3c00-4dad-b38c-0a4d2d85ffab ». Les variables de type 3 avaient déjà été définies dans la bibliothèque de variables d’Octopus.
Nous avons ensuite utilisé les variables de cette manière :
- Lorsque nous avons appelé le script Powershell dans Octopus, nous avons envoyé les variables définies dans Octopus au script.
- Dans le script Powershell, nous avons récupéré les variables Octopus envoyées et les avons assignées à des variables Powershell.
- Lorsque nous avons utilisé la commande Newman dans le script Powershell, nous avons transmis les variables du script à l’environnement Postman.
- Newman utilisait les variables transmises dans le script Powershell, combinées aux variables dans l’environnement Postman, pour exécuter la collection Postman.
Avec nos tests de vérification API automatisés exécutés dans Octopus pour chaque API et dans chaque environnement, nous pouvons être sûrs que tout problème majeur lors d’un déploiement d’API sera détecté immédiatement. De plus, nous pouvons tester dans des environnements de Production même sans accès aux clés API sensibles. Le fait d’avoir des tests de déploiement automatisés nous libère pour réaliser d’autres types de tests, comme les tests exploratoires manuels et les tests de sécurité, ainsi que pour écrire davantage d’automatisation des tests pour les régressions nocturnes.
Pour plus de guides pratiques, abonnez-vous à la newsletter The QA Lead.
Poursuivez votre apprentissage et découvrez ce podcast : COMMENT LES LOGICIELS OPEN SOURCE SIMPLIFIENT L’INTÉGRATION EN INGÉNIERIE DE L’AUTOMATISATION (AVEC JAMES WALKER ET SANJAY KUMAR)
