L'écriture de tests unitaires qui garantissent le bon fonctionnement des sections individuelles d'une application ou d'un service est un processus profondément ancré dans le flux de travail de la plupart des développeurs. Les tests d'intégration sont une autre forme de test qui est sans doute plus difficile à inclure dans vos projets. Les tests d'intégration vous permettent de vous assurer que toutes les différentes unités de code qui composent votre application peuvent fonctionner ensemble de manière cohérente sans aucun problème. Cela implique généralement de tester une version déployée de votre code et, de ce fait, les tests d'intégration sont généralement considérés comme longs et difficiles à créer. Postman est un outil très utile qui peut vous aider à créer des tests d'intégration.
Postman fournit aux développeurs un ensemble d'outils qui prennent en charge chaque étape du cycle de vie des API. Le cas d'utilisation le plus fréquent pour un développeur consiste à déboguer une API récemment modifiée ou interrompue en envoyant une requête au terminal en question. Bien que cet exemple soit certainement utile à une équipe de développement, il ne s'agit que d'un petit aperçu de tous les avantages qui peuvent être obtenus en utilisant Postman. Une autre fonctionnalité très puissante mais sous-utilisée de l'ensemble d'outils de Postman est la possibilité de créer et d'exécuter automatiquement une collection de tests.
Tests Postman
Une requête typique adressée à un backend hébergé localement à l'aide de l'application de bureau Postman peut ressembler à ceci :
Cette demande n'est pas du tout complexe, en fait, elle est à peu près aussi simple que possible, mais elle accomplit son travail de communication avec le backend hébergé localement et de renvoi d'une réponse. Avec Postman, nous pouvons créer des tests élégants pour nos terminaux à l'aide de quelques lignes de code. Supposons, par exemple, que nous voulions créer un test pour le point de terminaison spécifié ci-dessus et nous assurer que toutes les requêtes qui lui sont adressées renvoient un 200 HTTP code d'état. Il suffit d'entrer dans l'onglet « tests » de la requête Postman et de commencer à rédiger le test.
Sur le côté droit de l'onglet de test se trouve une liste de liens qui génèrent du code pour faciliter un peu les tests via Postman. La suite de tests Postman est dotée d'un ensemble de fonctionnalités utiles telles que la configuration de variables d'environnement et de variables globales à utiliser dans les corps de requêtes suivants, la conversion du type de contenu de réponse et la configuration de définitions d'objets de réponse à valider automatiquement. Plus d'informations sur la syntaxe des tests Postman et sur la façon de les créer peut être trouvé ici.
Poursuivant ce test, nous renvoyons la demande et nous nous assurons que notre test est réussi.
Maintenant que nous sommes satisfaits de notre nouveau test, nous pouvons enregistrer notre demande avec son test dans une collection Postman. Les collections vous permettent d'organiser les demandes en groupes logiques. Ces collections peuvent ensuite être partagées avec d'autres développeurs en utilisant des liens partageables ou en exportant la collection dans un fichier JSON qui peut ensuite être partagé de n'importe quelle manière. Nous aimons conserver les collections de tests dans le contrôle des sources afin que chaque développeur dispose d'un emplacement central où extraire les tests. Nous utilisons également des liens partageables pour partager des collections avec les membres de notre équipe de produits et de test. Ce faisant, nous sommes en mesure de fournir au personnel non ingénieur la possibilité de tester rapidement les terminaux de notre environnement de développement sans avoir à extraire du code ou à exécuter des serveurs encombrants localement.
Environnements Postman
Avant de passer à la création de nombreuses requêtes et tests, il peut être utile de comprendre comment fonctionnent les environnements de Postman. Ils vous permettent essentiellement de stocker un ensemble de paires de clés ou de valeurs qui peuvent être utilisées dans les requêtes et les tests. Pour en savoir plus à leur sujet, cliquez ici.
L'un des points importants à prendre en compte est que les environnements peuvent également être partagés de la même manière que les collections.
Gérer une collection Postman localement
Avec tout cela à l'esprit, nous pouvons maintenant répéter le processus de création de requêtes et de tests pour tous les points de terminaison de notre serveur. Il est conseillé de créer des tests couvrant un large éventail d'exigences, par exemple de créer un test garantissant que l'un des points de terminaison doit renvoyer un corps contenant certains champs de données. Une fois que l'ensemble de requêtes est rempli avec d'excellents tests enregistrés, configurez Postman pour exécuter ces tests tous ensemble sous forme de collection.
Pour lancer une collection, localisez le « lanceur » du test qui se trouve dans le coin supérieur gauche.
À partir de là, sélectionnez la collection et tout environnement créé pour cette collection. Ensuite, lancez la collection et si tout se passe bien, un cercle vert indiquera le nombre de tests réussis. Plus bas, la fenêtre affiche des informations détaillées sur les tests et les requêtes individuels, telles que la durée de chaque demande et les instructions d'assertion qui ont réussi.
Intégrer ces collections dans la construction/le déploiement de Bamboo
Avec cette incroyable série de tests pour ces terminaux, ne serait-il pas agréable de pouvoir l'intégrer au processus de création et de déploiement de Bamboo ? Plus précisément, ce serait plutôt cool d'exécuter une collection Postman sur un déploiement pour s'assurer que les modifications de code fonctionnent dans le monde réel. Eh bien, il y a de mauvaises et de bonnes nouvelles. Malheureusement, les tests d'intégration de Postman ne sont pas pris en charge nativement dans Bamboo, mais là où il y a une volonté, il existe un moyen. Cette « méthode » n'est pas exactement la forme la plus élégante pour effectuer des tests dans Bamboo, mais elle permet d'atteindre l'objectif suivant :
Être en mesure d'exécuter une série de tests Postman dans le cadre d'un déploiement de l'un de nos services principaux.
L'équipe de Postman a développé et publié un package npm très utile nommé Newman. Newman permet aux utilisateurs d'invoquer les collections de tests Postman via une interface CLI et, comme il est développé dans node.js, il peut facilement être invoqué lors d'un plan de construction ou de déploiement dans Bamboo. Cependant, Bamboo ne prend pas directement en charge les tests d'intégration pour les déploiements. La collection peut être exécutée juste après le déploiement à l'aide d'un script pour invoquer Newman, mais il n'existe aucun moyen direct d'analyser les résultats et de les lier à ce déploiement. Pour surmonter cet obstacle, nous devons nous salir un peu les mains.
La solution que nous avons mise en œuvre impliquait l'exécution de notre collection Postman pendant le plan de déploiement, le téléchargement des résultats des tests dans un compartiment Amazon S3, l'appel d'un plan de génération complètement distinct via un appel d'API, puis l'extraction et l'analyse de ces résultats de test dans ce plan de génération. Ce n'était certainement pas ce que nous avions en tête lorsque nous avons pensé pour la première fois à intégrer Postman à Bamboo. La conception présente certaines limites, mais elle fait l'affaire.
Même s'il est possible de déclencher un autre plan de construction à partir d'un déploiement réussi à l'aide de déclencheurs Bamboo, nous avons choisi de ne pas suivre cette approche. Nous voulions nous assurer que nos tests de collecte Postman seraient exécutés et correctement analysés pour chaque déploiement réussi. Pour ce faire, nous avons indiqué à notre deuxième plan de construction où trouver les résultats des tests qu'il devait analyser. Si nous avions essayé d'utiliser des déclencheurs pour faire le même travail, nous aurions rencontré le problème de ne pas pouvoir indiquer à la version où trouver les résultats des tests. Nous aurions pu spécifier un emplacement statique où nous écririons les derniers résultats des tests, mais certains scénarios extrêmes utilisant cette approche auraient pu entraîner la non-analyse de certains résultats de test. Cela dit, utiliser des déclencheurs pour invoquer le plan de construction au lieu d'un appel d'API est une stratégie tout à fait valable et je suis sûr qu'il existe des solutions aux problèmes susmentionnés.
Configuration d'une collection Postman à exécuter après le déploiement
Avant de pouvoir commencer le processus de configuration de notre collection pour qu'elle s'exécute après le déploiement de notre service, nous devions nous assurer que notre plan de déploiement avait accès à la collection et aux environnements que nous voulions utiliser. L'un des moyens d'y parvenir est de stocker la collection et les environnements dans un système de contrôle de source. Dans ce cas, créez une tâche au début du déploiement pour extraire la collection et les environnements du référentiel distant. Dans notre cas, nous avons décidé de simplifier les choses et de stocker nos collections en fonction du code avec lequel nos tests de collection interagissent. Cela signifiait que nous avions déjà accès à nos tests de collecte dans le plan de construction qui a précédé notre plan de déploiement.
Dans le plan de construction, nous avons extrait le référentiel de notre service, effectué nos tests unitaires et créé nos artefacts. L'un des artefacts que nous avons créés à partir de notre build était constitué des collections Postman et des environnements que nous voulions tester après le déploiement.
Dans le plan de déploiement, nous avons ajouté une tâche permettant de télécharger cet artefact à partir de la version précédente.
Avec l'accès à la collection, nous avons commencé à travailler sur la configuration de l'exécution de la collection et des tests. Afin d'exécuter la collecte sur les terminaux récemment déployés, nous avons créé une tâche supplémentaire à la fin du déploiement. La tâche supplémentaire a invoqué un script qui a utilisé Newman pour exécuter les tests Postman. Nous avons décidé d'inclure ce script dans l'artefact de construction contenant notre collection Postman pour en faciliter l'accès.
La manière dont vous configurez votre script dépend de vous, mais si vous souhaitez suivre l'approche que nous avons utilisée, vous devrez inclure quelques sections de code. Tout d'abord, installez Newman et dites-lui d'exécuter votre collection Postman.
Lorsque vous exécutez Newman, vous pouvez spécifier l'emplacement où vous souhaitez que les résultats de vos tests de collecte soient stockés. Dans l'extrait de code ci-dessus, nous utilisons la variable $Folder.
Ensuite, pour télécharger les résultats des tests, utilisez l'AWS CLI. Pour nous assurer que chaque fichier de résultats de test est identifiable de manière unique, nous avons choisi d'ajouter la variable bamboo_deploy_release à la fin de chaque nom de fichier de résultat de test.
À partir de là, invoquez le plan de construction qui analysera les résultats des tests. Nous avons transmis la même variable bamboo_deploy_release afin de pouvoir identifier et télécharger le bon ensemble de résultats de test.
Analyse et communication des résultats des tests de collecte
Une fois que tout cela est configuré, créez le plan de construction et configurez-le pour analyser les résultats des tests de collecte. Si vous connaissez le bambou, ce sera assez facile à réaliser. Tout d'abord, nous devons créer le plan.
Ensuite, nous devons configurer le plan et y ajouter quelques tâches.
Nous avons vérifié l'un des référentiels qui contenait un script shell que nous avons créé pour télécharger les résultats des tests de collecte depuis S3.
Enfin, nous avons utilisé JUnit pour analyser les résultats des tests.
Si vous avez tout configuré correctement chaque fois que le déploiement a lieu, votre collection Postman doit être exécutée et les résultats doivent être consignés dans le plan de construction créé ci-dessus.
Un résumé des événements qui se sont produits
Changement de code sur la branche -> La construction de Bamboo commence par un déclencheur -> La compilation passe, les artefacts de la collection Postman sont créés -> Le déploiement de Bamboo commence par un déclencheur -> Le déploiement de Bamboo récupère les artefacts de Bamboo build -> Le déploiement de Bamboo exécute votre script Postman PowerShell -> La collection Postman est exécutée -> Les résultats sont téléchargés vers S3 -> Une version séparée de Bamboo est déclenchée par un appel d'API -> Une version distincte de Bamboo exécute votre script de téléchargement et analyse les résultats des tests de collection
Problèmes et choses que nous aurions pu améliorer
En raison de la nature de la mise en œuvre, il y avait un léger décalage entre le déploiement du service et les collections Postman qui s'y opposaient. Bamboo ne prenant pas en charge les tests d'intégration de manière native, nous avons fini par analyser les résultats des tests dans un plan de construction distinct. Cela posait problème car cela créait un fossé entre le déploiement et les tests. Si certains tests de Postman échouent, le déploiement sera tout de même considéré comme un succès : en ce qui le concerne, l'entreprise a réalisé toutes ses tâches avec succès. Cela peut rendre le processus de recherche de la cause première des échecs de test plus difficile qu'il ne devrait l'être.
Malgré ses problèmes, la solution que nous avons mise en œuvre s'est révélée bénéfique, comme en témoigne l'amélioration de la connaissance de l'état des services. Si nos tests de collecte Postman échouent pour une raison ou une autre, nous pouvons configurer des alertes qui avertiront l'équipe de développement désignée. Si cette situation se produit, les résultats des tests de la collection Postman aident les développeurs à diagnostiquer et à comprendre les problèmes présents. En consultant les résultats des tests de collecte dans Bamboo, un développeur peut facilement voir quels tests ont échoué et lesquels ont réussi. Sans de tels tests d'intégration, les problèmes et les bogues deviennent de plus en plus difficiles à identifier et à résoudre.
.jpg)
.jpeg)
