Découvrez GoogleTest certifié TÜV avec Agentic AI pour les tests C/C++ !
Plus de détails »
Livre blanc
Avant de vous lancer, consultez les points saillants de notre livre blanc ci-dessous.
En tant qu'architecture de systèmes complexes, les microservices gagnent en popularité auprès des développeurs. Bien qu'il soit de plus en plus admis qu'il ne s'agit pas d'une solution miracle à tous les problèmes d'architecture applicative, les applications confrontées à des défis communs liés aux dépendances et à la mise à l'échelle peuvent en tirer un grand profit.
Avec l'adoption croissante des microservices, comprendre comment les tester devient un enjeu majeur. Tester les interfaces entre les services est complexe. Il existe cependant une méthode robuste pour tester les API et ainsi améliorer les déploiements de microservices.
À certains égards, test d'une application de microservices Tester une application construite selon une architecture différente de celle utilisée pour les microservices ne diffère pas de la nôtre. Les microservices utilisent des technologies éprouvées, telles que REST ou les files d'attente, pour lesquelles l'industrie dispose déjà d'outils de test et de bonnes pratiques bien établis.
Le défi unique posé par les microservices réside dans le nombre considérable de services qui composent une application, ainsi que dans les dépendances qui les unissent. De plus, chaque microservice doit continuer à fonctionner correctement même lorsque les autres microservices dont il dépend sont indisponibles ou présentent des dysfonctionnements.
Ce livre blanc technique explore les stratégies de test pour les architectures de microservices, couvrant les modèles d'orchestration et de chorégraphie, les approches de virtualisation des services et les meilleures pratiques pour la création de tests automatisés dans des systèmes distribués complexes.
La première étape pour comprendre les tests de microservices consiste à avoir une compréhension commune des modèles de messagerie communs qui décrivent leur comportement.
Les microservices reposent sur le principe qu'il s'agit de services légers et indépendants, exécutés comme des processus déployables individuellement, utilisant la technologie que l'équipe juge optimale pour son projet. Ces microservices sont souvent regroupés en fonctions et domaines métiers, dont la composition représente le système testé.
Les microservices suivent généralement deux modèles lors de leurs interactions :
De nombreux microservices utilisent une approche hybride. Dans cet article, nous présentons certains des défis rencontrés lors de la création de tests automatisés pour les microservices utilisant ces différents modèles, et nous proposons des stratégies pour y remédier. Nous nous concentrerons sur les tests de microservices individuels plutôt que sur les tests de microservices complets. tests de bout en bout de l'ensemble de la demande.
Un microservice utilisant l'orchestration effectue un ou plusieurs appels explicites à des services externes ou à des dépendances. Ces appels suivent généralement un flux requête-réponse synchrone et accèdent souvent à des services REST. Si les services doivent être appelés dans un ordre précis, l'appel à un service ultérieur n'est effectué qu'après réception d'une réponse à un appel au service précédent. Du fait de ces appels explicites, les services sont fortement couplés.
Dans cet exemple, le service Portfolio assure le suivi des positions boursières d'un utilisateur. Lors de l'ajout d'une position au portefeuille, le service Portfolio interroge le service REST Accounts afin de vérifier que l'utilisateur dispose des fonds nécessaires sur son compte. Une fois la réponse de Accounts obtenue, il interroge le service REST Quotes pour consulter le cours actuel de l'action. Dès réception de la réponse de Quotes, le service Portfolio peut finaliser l'ajout de la nouvelle position.
La création et l'exécution de tests pour le microservice Portfolio présentent des difficultés pour les raisons suivantes :
Une solution consiste à utiliser la virtualisation de services pour simuler les réponses des microservices Comptes et Devis. solution de virtualisation de serviceDes outils comme Parasoft Virtualize vous permettent de définir des versions virtuelles des microservices Comptes et Devis et de les déployer parallèlement à l'instance physique du microservice Portefeuille. La virtualisation des microservices est similaire à la virtualisation de tout autre type de service ou d'architecture applicative.
Une fois cela fait, le microservice Portfolio peut être testé indépendamment de ses deux dépendances.
Le défi suivant consiste à configurer différents environnements pour différents cas de figure, par exemple lorsque les services Comptes et Cotations présentent des comportements attendus ou inattendus. Supposons que l'équipe souhaite tester le comportement du service Portefeuille lorsque le service Comptes ou le service Cotations répond lentement ou génère des erreurs. Cela peut nécessiter l'exécution d'au moins cinq séries de tests différentes, chacune avec une configuration d'environnement distincte.
| Essai de fonctionnement | Configuration du service de comptes | Configuration du service de devis |
|---|---|---|
| Comportement normal | Comportement normal | Comportement normal |
| Les comptes ont un temps de réponse lent. | Réagit lentement | Comportement normal |
| Réponses d'erreur de compte | Répond avec des erreurs | Comportement normal |
| Les devis sont lents à répondre | Comportement normal | Réagit lentement |
| Réponses d'erreur de citation | Comportement normal | Répond avec des erreurs |
Pour chaque exécution de test, l'environnement doit être configuré correctement avant que les tests correspondants puissent être lancés. Dans cet exemple, nous avons au moins cinq exécutions de test différentes, chacune avec sa propre configuration d'environnement. Le module Gestionnaire d'environnement de la plateforme de tests continus (CTP) Parasoft permet de gérer ces différentes configurations.
Ce que nous avons décrit dans cet exemple n'est pas spécifique à une architecture de microservices. Des problèmes similaires se posent dans les architectures orientées services en général, ainsi que dans les applications monolithiques qui ne dépendent que de quelques services. Dans une architecture de microservices, cependant, le nombre de services dépendants augmente considérablement. Dans cet exemple simple avec seulement trois microservices, on constate déjà que le nombre de configurations d'environnement différentes peut croître rapidement lorsqu'on tente de tester différents états de l'application. Dans un environnement de microservices comportant des dizaines, voire des centaines de services, la capacité de créer, de gérer et de basculer par programmation entre différentes configurations d'environnement pour différents scénarios de test est essentielle.
À mesure que les équipes font évoluer leurs microservices, des modifications d'API sont inévitables. Un problème majeur lié à ces modifications est la compréhension de leur impact sur les utilisateurs. Le secteur s'oriente vers les tests de contrat pour y remédier. Cependant, un autre problème, souvent négligé, a émergé : comment mettre à jour efficacement les scénarios de test et les ressources virtuelles de l'infrastructure de test afin de refléter les API mises à jour ?
Lorsqu'une équipe modifie l'API d'un microservice en cours de développement, les tests validant ce microservice doivent être mis à jour en fonction de ces modifications. Inversement, si des services virtuels sont utilisés pour simuler des microservices dépendants et qu'une modification de l'API de l'un de ces microservices dépendants est apportée, les services virtuels correspondants doivent être mis à jour pour refléter ces modifications.
De nombreuses équipes utilisent OpenAPI, RAML ou une autre définition de service pour décrire les API de leurs microservices. Grâce à Change Advisor, intégré à Parasoft SOAtest et Parasoft Virtualize, les définitions de service permettent de détecter automatiquement les API modifiées et de refactoriser automatiquement les tests fonctionnels ou services virtuels existants afin de les mettre à jour avec les nouveaux champs et/ou les champs supprimés. Les équipes peuvent ainsi créer des versions mises à jour de leurs définitions de service et utiliser Change Advisor pour anticiper l'impact des modifications sur leurs tests et services virtuels avant de les appliquer. Une fois les modifications effectuées, Change Advisor simplifie et accélère la mise à jour des ressources existantes pour refléter les changements au sein des microservices.
L'un des principaux objectifs d'une architecture de microservices est de créer des composants indépendants. De ce fait, le déploiement, la mise à l'échelle et la mise à jour des services s'en trouvent simplifiés. Toutefois, cet objectif n'est pas pleinement atteint avec le modèle d'orchestration, car chaque microservice dépend directement d'autres microservices. Une solution consiste à utiliser le modèle de chorégraphie, également appelé microservices « réactifs » ou « événementiels ». Dans ce modèle, les microservices ne se référencent pas directement. Ils envoient plutôt des messages sur des flux d'événements auxquels d'autres microservices sont abonnés.
Dans cet exemple, supposons que le service Portfolio ait reçu l'instruction d'ajouter une position boursière. Au lieu d'appeler directement le service Accounts, il publie un événement dans le flux d'événements « Position ajoutée ». Le microservice Accounts est abonné à ce flux et reçoit donc la notification. Il vérifie que l'utilisateur dispose de fonds suffisants sur son compte. Si c'est le cas, il réduit le solde et publie un événement dans le flux d'événements « Compte mis à jour ». Si l'utilisateur ne dispose pas de fonds suffisants, il peut publier un événement d'erreur dans un autre flux d'événements (non représenté ici pour simplifier l'exemple). Le microservice Portfolio est abonné au flux d'événements « Compte mis à jour » et, lorsqu'il reçoit l'événement publié par le microservice Accounts, il met à jour son portefeuille en fonction de la confirmation du service Accounts.
La communication asynchrone de ce type d'architecture présente l'avantage d'un découplage important des services : les instances de chaque service peuvent être remplacées, redéployées ou mises à l'échelle sans impacter les autres microservices. En contrepartie, la nature asynchrone des événements complexifie la compréhension du fonctionnement du système et du flux d'événements. Selon l'ordre ou la nature des événements produits, le système peut adopter un comportement inattendu. Ce phénomène, appelé comportement émergent, constitue un défi inhérent au développement et aux tests de microservices orchestrés.
Il existe différents modèles de messagerie asynchrone qui relèvent de la catégorie plus large des microservices événementiels.
Le modèle d'appels de commandes asynchrones est utilisé lorsque des microservices doivent être orchestrés à l'aide d'actions asynchrones : un microservice doit appeler un autre microservice de manière asynchrone, tout en garantissant la réception du message par ce dernier. Dans ce modèle, les messages sont généralement échangés via des files d'attente. RabbitMQ est un framework couramment utilisé dans les architectures de microservices pour implémenter ce modèle.
Ce modèle se manifeste notamment lorsqu'un microservice doit publier un événement destiné à être traité par un second microservice, puis attendre la réponse de ce dernier. Ce comportement a été décrit précédemment lors de la présentation du modèle de chorégraphie des microservices.
Dans cet exemple, un appel à l'API REST demande au microservice Portfolio d'ajouter une position. Le service Portfolio envoie un événement à la file d'attente « Position ajoutée » pour que le microservice Accounts le traite, puis attend que ce dernier envoie un événement de réponse à la file d'attente « Compte mis à jour » afin que l'appel à l'API REST puisse renvoyer les données reçues de cet événement. Il existe deux manières différentes de configurer un scénario de test pour cet exemple.
Les tests doivent être configurés pour s'exécuter simultanément afin que l'événement provenant du service Accounts soit publié pendant que le service Portfolio est à l'écoute de cet événement.
La première approche est simple et permet de créer un environnement de test autonome, sans dépendance externe vis-à-vis de l'infrastructure de test. La seconde approche est réutilisable et simule plus fidèlement le comportement réel du système. Cependant, elle implique la création, le déploiement et la gestion d'un environnement virtuel distinct.
Une variante de ce modèle consiste en un microservice qui écoute une file d'attente pour un événement entrant, traite cet événement, puis publie un événement de suivi sur une autre file d'attente pour qu'un ou plusieurs autres microservices puissent le traiter.
Dans cet exemple, le microservice Facturation est celui qui doit être testé. Le service Paiements publie un événement dans la file d'attente RabbitMQ « Paiement traité » afin que le service Facturation le prenne en charge. Le microservice Facturation lit cet événement, crée une facture, puis publie un événement dans la file d'attente « Facture créée » pour indiquer au microservice E-mail d'envoyer un e-mail au client contenant la facture.
Pour créer un scénario de test pour le microservice Facturation, un environnement de test est configuré. Cet environnement comprend deux files d'attente RabbitMQ et le microservice Facturation déployé. À l'aide du transport personnalisé RabbitMQ inclus dans le pack IoT/Microservices du Parasoft Marketplace, un scénario de test Parasoft SOAtest est construit. Ce scénario publie un événement de paiement traité dans la file d'attente « Paiement traité ». Il s'abonne ensuite à la file d'attente « Facture créée » afin de vérifier que l'événement de création de facture correspondant est bien publié en réponse par le service Facturation.
Le modèle de flux d'événements en continu est utilisé lorsque différentes sources produisent un très grand nombre d'événements qui doivent être distribués rapidement à différents consommateurs via un hub commun. Dans ce modèle, les messages sont échangés par le biais de sujets, tandis que dans le modèle d'appels de commandes asynchrones évoqué précédemment, les messages sont échangés par le biais de files d'attente. Le framework Apache Kafka est couramment utilisé pour implémenter ce modèle.
Supposons que nous voulions tester un seul microservice qui s'abonne à un sujet Kafka, traite les événements qu'il reçoit, puis publie ses résultats sur un deuxième sujet Kafka.
Dans cet exemple, nous avons un microservice Forecast qui s'abonne à un topic de données météorologiques collectant de nombreuses données provenant de diverses sources. Il traite ensuite ces données pour mettre à jour son modèle de prévision et publie les prévisions sur le topic de données de prévision. Il est nécessaire de vérifier que le service Forecast publie bien les événements attendus sur le topic de données de prévision pour un ensemble spécifique d'événements météorologiques. Pour ce faire, nous configurons un environnement de test comprenant les deux topics Kafka et le service Forecast déployé.
Nous construirions un scénario de test utilisant Parasoft SOAtest et le transport personnalisé Kafka inclus dans le pack IoT/Microservices. Marché Parasoft. Le scénario de test commencerait par publier les événements nécessaires sur le sujet « Données météorologiques », puis s'abonnerait au sujet « Données de prévision » afin de vérifier que le service de prévision publie bien les événements de données de prévision attendus. Plusieurs scénarios de test différents devraient être élaborés pour vérifier les différents types et l'ordre des événements susceptibles d'être traités par le microservice de prévision.
Il s'agit d'un scénario de test relativement simple. Le fait que le microservice Forecast soit découplé des autres microservices a pour heureux effet que le test du service Forecast est lui aussi découplé des microservices. Dans ce cas, il n'est pas nécessaire de configurer un environnement complexe avec des services virtuels. Il suffit de créer des scénarios de test qui publient des événements et de vérifier que les événements attendus sont bien générés en réponse.
De nombreuses équipes de microservices ont adopté un processus CI/CD pour la construction, le test et le déploiement de microservices conteneurisés, afin d'automatiser le processus et de réduire les risques liés aux mises à jour. Dans ce processus, une image conteneurisée du microservice est automatiquement créée et déployée dans un environnement de test, souvent géré par Kubernetes ou une distribution basée sur Kubernetes comme OpenShift. Le microservice peut ainsi être validé avant d'être soumis à des tests de bout en bout, puis mis en production.
Nous avons constaté que la virtualisation des services est utile, voire essentielle, pour la création de scénarios de test de microservices. Lorsque les environnements de test reposent sur des technologies comme Docker ou Kubernetes, les outils utilisés pour créer et déployer des services virtuels doivent s'y intégrer parfaitement. Services virtuels Les applications doivent être hautement modulaires et facilement déployables, pour les mêmes raisons que les microservices qu'elles simulent. Or, les fournisseurs de virtualisation de services traditionnels ne répondent pas à ce besoin, car leurs applications sont monolithiques, centralisées et utilisées par plusieurs équipes.
Pour que la virtualisation des services fonctionne dans ces environnements, il est nécessaire de créer des services virtuels conteneurisés faciles à déployer. Pour créer un service virtuel conteneurisé, on utilise une image de base contenant Parasoft Virtualiser et toutes ses dépendances, et la superposer à une autre image contenant toutes les configurations des ressources virtuelles du service virtuel. La nouvelle image du service virtuel serait déployée comme conteneur dans l'environnement Docker/Kubernetes, avec le conteneur du microservice testé et toutes ses dépendances (virtualisées).
Les modèles de messagerie et les modèles de test associés présentés dans cet article ne sont pas nouveaux, mais leur utilisation est devenue essentielle avec la généralisation des microservices et l'adoption croissante de ce paradigme par les applications. Les outils SOAtest, Virtualize et… de Parasoft en sont des exemples. CTP permettre aux équipes de créer et de déployer des scénarios de test pour les microservices avec une flexibilité maximale, garantissant ainsi la haute qualité et la fiabilité de leurs microservices.
Prêt à plonger plus profondément ?
