Rawpixel - Fotolia
Les quatre étapes fondamentales du test de microservices
Les nouveaux venus dans le monde des microservices s’aperçoivent rapidement que les méthodes de tests traditionnels ne sont pas adaptées. Dans cet article, nous nous penchons sur la manière d'aborder quatre tests critiques de microservices.
Les microservices fonctionnent indépendamment les uns des autres. Ils communiquent vers d’autres services en appelant des API. Tester les applications reposant sur cette architecture est compliqué, car le responsable de la procédure doit prendre en compte non seulement d'un service donné, mais aussi ses dépendances - et planifier la stratégie de test en conséquence.
Au vu de ces propriétés, les testeurs, qu’ils soient un développeur ou un membre de l’équipe assurance qualité, ont besoin de traiter chaque service indépendamment. Une stratégie de tests efficace consiste à isoler les composants afin de vérifier que l’entièreté du système fonctionne correctement.
Il y a quatre tests fondamentaux à appliquer aux microservices : tests unitaires, d’intégration, des composants et contractuels. Cet article décrit comment vérifier la qualité des microservices à chacune de ces étapes. Il mentionne également les outils pertinents à mettre en place dans le cadre cette stratégie.
Le test unitaire
Le test unitaire valide que le code de chaque composant d’une application respecte la ligne directrice émanant des logiques métiers. Cette étape représente le gros du travail, car il s'agit de vérifier de nombreuses classes et fonctions. Elle est cruciale quand une entreprise utilise des applications basées sur des microservices.
La taille des différentes unités de composant n’est pas standard. Celles-ci peuvent reposer sur un gros bloc de code comme sur quelques lignes. Pour vérifier précisément les performances des microservices, il faut faire en sorte de réduire la taille de ces unités. Les unités les plus grandes des services distribués, impliquent la conduite de tests d’une complexité imprévisible à mesure que ces services consomment davantage de ressources.
Les frameworks open source de tests unitaires Xunit ou la fonction d’enregistrement de code sont idéaux pour les appliquer aux microservices.
Le test d’intégration
Les tests d’intégration servent à valider comment les unités fonctionnent ensemble et avec leurs dépendances. Souvent, plusieurs microservices interagissent ensemble. Les testeurs doivent suivre les requêtes échangées entre les services afin de s’assurer que les canaux de communication associés soient opérationnels.
Pour effectuer ces tests d’intégration, les outils automatisés comme ceux de Katalon Studio ou le projet open source Selenium sont recommandés.
Le test de composants
Les tests de composants permettent d’isoler les composants ou les services d’une application. Si aucune erreur ne ressort de ces examens individuels, il est possible d’émuler les éléments associés. Un pratique nommée « Mocking » en anglais et qui émane de la programmation orientée objet.
Pour ce faire, ils permettent de créer des services fictifs qui reflètent le service déployé. Les tests de composants valident l'interaction entre un service distribué et ses dépendances, telles que la base de données et les composants tiers.
Hoverfly et d’autres simulateurs d’API permettent de préparer ces tests tout comme les outils de mocking (simulation d’une couche service) et de stubbing (imitation du comportement d’objets ou de données).
Le test contractuel
Les tests contractuels sont différents des vérifications de fonctionnalité effectuées jusqu'à présent. Il permet de vérifier si les services qui communiquent avec des composants logiciels externes via des API répondent aux exigences légales nécessaires. Pour réussir le test, les appels et les réponses doivent produire les mêmes résultats à chaque fois, même si le service est modifié ou mis à niveau.
Ils sont particulièrement importants lorsque de nombreux services répartis exécutent des composants d'applications en production. Pour les appliquer aux microservices, il est vital que le producteur et le consommateur de services disposent de la version la plus récente du contrat. Pact est un outil populaire pour les tests de contrat et peut aider à faciliter la validation de ces logiciels.
NB : Dans cet ordre, il s'agit de la stratégie de test la plus répandue, qui répond à la plupart des besoins. D'autres envisagent ce procédé comme une pyramide et y ajoute des couches de vérification comme les tests de bout en bout, afin de constater le fonctionnement d'un workflow complet lié à une application en microservices. D'autres encore comme Spotify envisagent une approche basée sur des "vases communicants" où chaque étape est dépendante de la suivante et vice-versa.
