Webinaire en vedette : MISRA C++ 2023 : tout ce que vous devez savoir | Voir le séminaire

Surmonter les défis des tests de microservices et maximiser les avantages

Tête de Wilhelm Haaker, directeur, ingénierie de solutions, fonctionnel chez Parasoft
11 mai 2023
11 min lire

Les microservices jouent un rôle énorme dans les versions logicielles réussies. Voici une couverture des meilleures pratiques de microservices pour les entreprises.

Les microservices sont une tendance de l'industrie depuis des années, mais les organisations ne parviennent pas à récolter les bénéfices de l'approche et sont aux prises avec des versions qui échouent. Ces échecs se résument souvent à la difficulté de tester les interfaces entre les services pour obtenir la qualité, la sécurité et les performances attendues.

En fin de compte, c'est un échec de tester ces API de manière suffisamment robuste. La doublure argentée est que les concepts de test et les solutions entre les tests SOA hérités et les tests de microservices sont les mêmes. Si vous pouvez résoudre vos problèmes de test d'API, vous pouvez améliorer vos versions de microservices.

3 étapes clés pour des tests de microservices efficaces - Une présentation du monde des API

Les microservices introduisent de nouveaux défis

De nos jours, il est courant de voir des centaines, voire des milliers de microservices regroupés pour définir une architecture moderne.

Les systèmes d'entreprise hautement distribués ont des déploiements importants et complexes, et cette complexité du déploiement est souvent considérée comme une raison de NE PAS mettre en œuvre les microservices. En fait, la complexité du monolithe que vous êtes en train de décomposer ne fait que se désagréger en un environnement de déploiement encore plus complexe.

À la déception des non-initiés, la complexité ne disparaît pas vraiment et se transforme plutôt en un nouveau type de complexité.

Fitch offre une couverture et une qualité de code élevées pour les applications de microservices

Alors que les microservices promettent d'augmenter l'efficacité du développement parallèle, ils introduisent leur propre nouvel ensemble de défis. Voici quelques exemples.

  • Beaucoup plus d'interactions à tester au niveau de la couche API, alors qu'auparavant, les tests d'API se limitaient à tester uniquement les points de terminaison exposés à l'extérieur.
  • Obstacles parallèles au développement qui limitent les avantages du délai de mise sur le marché de la rupture du monolithe. Les dépendances vis-à-vis d'autres services et les environnements de déploiement complexes réduisent le parallélisme dans la réalité.
  • Impacts sur les méthodes traditionnelles de test qui ont réussi au sein du monolithe (comme les tests d'interface utilisateur de bout en bout) doivent maintenant passer à la couche API.
  • Plus de points de défaillance potentiels en raison des données et de l'informatique distribuées, ce qui rend le dépannage et l'analyse des causes profondes difficiles et complexes.

3 étapes clés pour tester les microservices

Quelles sont les trois étapes clés des tests de microservices ? Pour les décrire simplement, ces étapes sont :

  1. Enregistrement
  2. Surveiller
  3. Control

L'enregistrement, la surveillance et le contrôle vous aideront à mettre en œuvre des approches de test efficaces découvrir quels tests créer tout en vous aidant simultanément à automatiser les tests de composants lorsqu'il existe des API en aval dont vous devez vous isoler.

La technologie permettant d'y parvenir est la virtualisation des services. La virtualisation des services donne vie à ces 3 concepts grâce à une fonctionnalité fondamentale : les proxys de messages.

L'utilisation de proxys de message dans votre environnement de déploiement vous permet de surveiller et d'enregistrer les flux de messages entre les API, ainsi que de contrôler les destinations où les messages sont envoyés.

Comment fonctionne un proxy de messagerie ?

Il est conçu pour écouter un point de terminaison ou une file d'attente donné, puis transférer les messages qu'il reçoit vers un point de terminaison ou une file d'attente de destination. Fondamentalement, c'est un intermédiaire pour vos API. Vous choisissez activement d'en injecter un entre vos systèmes intégrés. Une fois qu'il est en place, vous êtes prêt à commencer à en profiter.

Graphique affichant un proxy de message représenté par un globe terrestre avec des papiers volant vers plusieurs ordinateurs portables autour de lui. Ci-dessous la mise à zéro dans un ordinateur portable qui relie aux bulles de toutes les fonctionnalités clés de la virtualisation des services, de la génération de la gestion des données de test à l'authentification et à la sécurité et bien d'autres.
Fonctionnalités clés de la virtualisation des services

Tests d'API et de microservices

Test des API et surmonter les défis qu'ils représentent n'est pas si différent que votre environnement soit hautement distribué, quelque peu distribué ou principalement monolithique. Plus le nombre d'intégrations existantes est élevé, plus certains des défis seront aigus, mais les approches fondamentales sont les mêmes.

Lorsqu'on pense à un API ou microservice en tant que boîte noire, nous pouvons le décomposer en clients de votre service et en dépendances de votre service. Tester votre API en tant que boîte noire signifie que votre harnais de test agit en tant que client de votre service dont le travail consiste à vérifier qu'il reçoit les bonnes réponses. Les dépendances sont ce que votre service doit intégrer pour fonctionner correctement. Il y a des optimisations à faire à la fois côté client et entre les dépendances.

Avant d'explorer ces optimisations, commençons par la phase de conception, où le microservice est planifié et où la stratégie de test doit commencer.

Le cycle de vie des microservices

Phase de conception : définir les exigences de clarté

Une bonne pratique de développement d'API bien acceptée consiste à implémenter une définition de service pendant la phase de conception. Pour les services RESTful, la spécification OpenAPI est couramment utilisée.

Ces définitions de service sont utilisées par vos clients pour comprendre quelles ressources et opérations votre service prend en charge et comment votre service s'attend à recevoir et envoyer des données. Dans les définitions de service pour les services REST, il y aura des schémas JSON qui décrivent la structure des corps de message, afin que les applications client sachent comment travailler avec votre API.

Mais les définitions de service ne sont pas seulement importantes pour aider les autres équipes à comprendre le fonctionnement de votre API, elles ont également des impacts positifs sur votre stratégie de test.

Vous pouvez considérer la définition de service comme un contrat. C'est la base pour commencer à élaborer une stratégie de gouvernance des API. L'un des plus grands défis des tests d'API, comme tout test de logiciel, est de faire face au changement.

Avec la popularité des pratiques Agiles, le changement n'a jamais été aussi rapide. L'application de ces contrats est la première étape pour mettre de l'ordre dans le chaos lorsque vous essayez de vous disputer avec de nombreuses équipes qui construisent des API et que vous vous attendez ensuite à ce que toutes ces API fonctionnent bien les unes avec les autres.

Validation et exécution des contrats

Comment fait-on pour faire respecter un contrat ?

Dans le cadre de toute suite de régression automatisée, vous devez vérifier si la définition de service que votre équipe a rédigée contient des erreurs. Swagger et OpenAPI ont leurs propres schémas qui définissent comment la définition de service doit être écrite. Vous pouvez les utiliser pour automatiser ces vérifications au début du cycle de vie du développement de l'API.

Ensuite, en plus de vérifier le contrat lui-même, vous souhaitez vérifier que les réponses renvoyées par votre service sont également conformes au contrat. Votre infrastructure de test d'API doit avoir une prise en charge intégrée pour intercepter les instances où votre API renvoie une réponse qui s'écarte du schéma de sa définition de service.

Pensez-y comme ça. Une voiture est composée de milliers de pièces individuelles qui doivent toutes s'adapter parfaitement.

Si l'équipe responsable de l'unité motrice fournit un moteur qui s'écarte des spécifications de conception, il est probable que vous ayez de gros problèmes lorsque vous essayez de brancher la transmission qu'une autre équipe a construite parce qu'elle faisait référence à la conception du moteur pour savoir où les boulons doivent s'aligner.

C'est ce que vous vérifiez ici. Ce sont les types de problèmes d'intégration qu'une bonne gouvernance des API peut vous aider à éviter. Concevoir et se conformer à ces contrats devrait être l'une des premières préoccupations de votre pratique de test d'API.

Les contrats de définition de service peuvent également aider votre processus de test à être plus résistant au changement. Le temps nécessaire pour refactoriser les cas de test pour les modifications d'une API pourrait avoir un impact énorme sur les tests, de sorte qu'il soit poussé en dehors du sprint.

Il s'agit à la fois d'un risque de qualité et de sécurité. Cela signifie également du temps imprévu pour des tests supplémentaires. Lors de l'utilisation d'un framework de test d'API, il doit aider les équipes à refactoriser en masse les cas de test existants à mesure que la conception d'une API change afin qu'ils puissent suivre le rythme rapide des tests Agile et en cours de sprint. Les contrats de service et le bon outillage peuvent rendre cela beaucoup moins pénible.

Phase de mise en œuvre : appliquer les meilleures pratiques

Le développement de microservices n'implique pas un laissez-passer gratuit pour ignorer les tests unitaires. Le code est le code et les tests unitaires sont une pratique de qualité fondamentale. Il aide les équipes à détecter les régressions rapidement, tôt et d'une manière facile à corriger pour les développeurs, quel que soit le type de logiciel.

La triste vérité est que les équipes logicielles avec des pratiques de test unitaire inexistantes ou réactives ont tendance à avoir des résultats de mauvaise qualité. Les frais généraux liés aux tests unitaires sont considérés comme trop importants et, par conséquent, de nombreux gestionnaires et dirigeants ne lui accordent pas la priorité.

C'est malheureux car le marché des outils a mûri où la vie d'un développeur est beaucoup plus facile et plus productive tandis que les tests unitaires et le compromis entre coût et qualité sont bien moindres qu'auparavant. Les tests unitaires constituent la base d'une pratique de test solide et ne doivent pas être lésés.

De plus, les pratiques de qualité logicielle pour les développeurs ont mûri avec des normes de codage dédiées au développement d'API. En 2019, l'organisation internationale à but non lucratif OWASP a publié le Norme de sécurité des API Top 10 de l'OWASP.

Des normes de codage comme celle-ci aident les équipes de microservices à éviter les anti-modèles courants de sécurité et de fiabilité qui pourraient introduire un risque commercial pour leurs projets. Essayer d'adopter une norme de codage sans outils est presque impossible.

Heureusement, les outils d'analyse statique modernes, également connus sous le nom d'outils de test de sécurité des applications statiques (SAST), restent à jour avec les normes de l'industrie et prendront en charge cette norme. Les développeurs peuvent analyser leur code au fur et à mesure qu'ils l'écrivent et dans le cadre de leur processus d'intégration continue pour s'assurer que rien ne manque.

Phase de test des composants : utiliser des proxys pour les dépendances d'API

Les tests de composants impliquent de tester votre microservice de manière isolée. Atteindre un véritable isolement présente des défis tels que savoir quoi faire des dépendances de votre microservice. De plus, l'une des choses les plus difficiles à anticiper en tant que développeur de microservices est de comprendre exactement comment votre API va être utilisée par d'autres systèmes.

Les applications clientes de votre API sont susceptibles de trouver des utilisations créatives de vos microservices qui n'ont jamais été envisagées. C'est à la fois une bénédiction commerciale et une malédiction technique, et c'est exactement pourquoi il est important de dépenser de l'énergie pour comprendre les cas d'utilisation de votre API.

La gouvernance de l'API pendant la phase de conception est une première étape importante, mais même avec des contrats bien définis et une validation de schéma automatisée des réponses de votre microservice, vous ne serez jamais en mesure de prédire pleinement l'évolution des besoins du produit de bout en bout. évoluer, et comment cela affectera les microservices au sein de votre domaine.

L'enregistrement, la surveillance et le contrôle vont vous aider à mettre en œuvre des approches de test qui découvrent efficacement les tests nécessaires tout en vous aidant simultanément à automatiser les tests de composants lorsqu'il existe des API en aval dont vous devez vous isoler. La technologie habilitante pour ce faire, c'est la virtualisation des services.

La virtualisation des services donne vie à ces trois concepts grâce à une fonctionnalité fondamentale : les proxys de messages. L'utilisation de proxys de message vous permet de surveiller et d'enregistrer les flux de messages entre les API, ainsi que de contrôler les destinations où les messages sont envoyés.

Graphique montrant comment le proxy de message se situe entre le client de l'API et le point de terminaison de l'API avec d pour l'enregistrement, la surveillance et le contrôle du trafic de l'API.
Un proxy de message se situe entre les clients et les points de terminaison pour enregistrer, surveiller et contrôler le trafic de l'API.

Services orchestrés vs chorégraphiés

Les services orchestrés et chorégraphiés (ou réactifs) sont des termes fantaisistes qui décrivent des modèles de messagerie synchrones ou asynchrones.

Si votre service communique à l'aide d'un courtier de messages avec des protocoles tels que AMQP, Kafka ou JMS, vous testez un service chorégraphié ou réactif.

Si vous testez une interface REST ou GraphQL, il s'agit d'un service orchestré ou synchrone.

Pour les besoins de cet article, peu importe le protocole et le modèle d'échange de messages auxquels vous êtes confronté. Cependant, vous trouverez peut-être plus difficile d'appliquer ces principes avec la messagerie asynchrone si votre infrastructure de test d'API ne prend pas en charge les protocoles que votre organisation a choisi d'adopter.

Capturez les scénarios d'utilisation du client

Il est difficile pour une équipe de microservices de prédire comment les autres équipes utiliseront leur API. Nous savons que les tests entièrement intégrés de bout en bout sont coûteux et lents. L'utilisation des fonctionnalités de proxy de message trouvées dans les outils de virtualisation de service vous permet d'enregistrer le trafic provenant des applications clientes en amont afin que vous puissiez capturer des scénarios d'utilisation réalistes qui améliorent considérablement votre connaissance des tests à exécuter dans votre pipeline CI/CD sans nécessiter que ces applications clientes être toujours présent pour déclencher ce trafic.

En d'autres termes, l'enregistrement vous permet de rejouer ces scénarios d'intégration pour des tests de régression automatisés, ce qui est beaucoup plus simple et facile à gérer que de demander aux clients d'exécuter leurs tests, qui testent de manière transitive votre API. C'est pourquoi les outils qui combinent la virtualisation des services avec les tests d'API sont si populaires. Ils facilitent l'enregistrement de ce trafic d'API, puis l'exploitent pour les tests de scénarios d'API qui sont placés sous votre contrôle.

Graphique montrant un moniteur sur la gauche générant un trafic d'API allant vers un proxy de message, puis vers un autre moniteur sur la droite affichant un scénario de test d'API.
Les clients génèrent un trafic d'API qui est enregistré par des proxys de messages. Ce trafic est organisé en scénarios de test d'API.

Rendre les dépendances gérables

Tester votre service devient rapidement difficile en raison de sa dépendance à d'autres API dans un environnement de test, ce qui pose des problèmes de disponibilité, de données de test réalistes et de capacité.

Cela peut pousser l'effort de test hors du sprint et rendre difficile pour les équipes de détecter les problèmes d'intégration suffisamment tôt pour avoir le temps de les traiter. Il s'agit du cas d'utilisation traditionnel de la virtualisation des services, où la technologie permet de simuler ou de se moquer des réponses des API en aval (ce faisant, de créer une version virtuelle du service) fournissant une isolation afin que vous puissiez tester pleinement votre API plus tôt et plus facilement avec votre pipeline CI/CD.

Graphique montrant une personne chargée de l'assurance qualité, un développeur et un ingénieur de test de performances essayant de tester un microservice dans un environnement réel avec son coût, ses limites de données de test et ses limites de capacité.
Essayer de tester un microservice dans son environnement réel est difficile en raison du manque de déploiement parallèle, des limitations des données de test et du manque de capacité.

Lorsque des proxys de message sont déployés dans un environnement, les équipes peuvent enregistrer le trafic API, puis créer des services virtuels qui répondent fidèlement et de manière réaliste au microservice (y compris des transactions avec état où la dépendance simulée doit gérer correctement les opérations PUT, POST et DELETE) sans avoir le réel dépendance disponible.

La virtualisation de service avec état est une fonctionnalité importante pour créer le service virtuel le plus réaliste qui couvre tous vos cas d'utilisation de test.

Graphique illustrant les services de test d'un responsable de l'assurance qualité, d'un développeur et d'un ingénieur de test de performances utilisant la virtualisation des services pour un environnement de test réaliste.
La virtualisation des services dissocie le service testé de l'environnement opérationnel tout en fournissant un environnement de test réaliste.

Phase de test intégrée : contrôler l'environnement de test

Dézoomons maintenant la portée des tests un peu plus loin sur les tests d'intégration. À ce stade, parfois appelé test d'intégration système ou stade SIT, l'environnement de test est un environnement de type production qui garantit qu'aucun défaut n'a été manqué.

Vous devez vous attendre à ce que les proxys de message permettent de contrôler si vous souhaitez une connexion isolée ou réelle aux dépendances. Un autre aspect du contrôle consiste à s'assurer que les proxys de message peuvent être facilement gérés via l'API. Les organisations ayant une grande maturité dans leurs processus CI/CD automatisent les flux de travail de déploiement et de destruction où le contrôle programmatique du proxy de message est une exigence incontournable.

Quelles optimisations pouvez-vous extraire de la visibilité (ou de l'observabilité) que les proxys de message exposent lorsque vous êtes dans la phase de test d'intégration ?

C'est là que les capacités de surveillance sont essentielles pour une solution de virtualisation des services qui prend en charge les tests automatisés. La surveillance des proxys de messages exposera le fonctionnement interne de ces flux de travail complexes afin que vous puissiez mettre en œuvre un meilleur test qui vous indique où se situe le problème, et pas seulement qu'un problème existe.

Considérons, par exemple, un système de traitement des commandes qui doit vérifier plusieurs services en aval tels que les systèmes d'inventaire, de facturation et d'expédition pour exécuter une commande. Pour une entrée de test donnée, vous pouvez vous opposer à certains comportements en coulisse qui aident les développeurs à déterminer pourquoi un test échoue. Lorsque votre équipe passe moins de temps à comprendre pourquoi un problème est survenu, elle a plus de temps pour le résoudre.

Graphique illustrant le flux d'intégration des partenaires au flux de travail des bons de commande pour les produits, la facturation et les microservices d'expédition.
La virtualisation des services permet d'affirmer le comportement pour aider à tester ou déboguer des scénarios qui seraient difficiles à reproduire dans un environnement opérationnel.

Cinq conseils pour tester les microservices

Voici cinq conseils pour vous aider à développer une stratégie de test de microservices. Gardez à l'esprit qu'il s'agit de suggestions. Comme pour tous les types de plans de test, vous devez tenir compte des spécificités de votre configuration.

  1. Considérez chaque service comme un module logiciel. Effectuez des tests unitaires sur un service comme vous le feriez sur n'importe quel nouveau code. Dans une architecture de microservices, chaque service est considéré comme une boîte noire. Par conséquent, testez chacun de la même manière.
  2. Déterminer les liens fondamentaux dans l'architecture et les tester. Par exemple, s'il existe un lien solide entre le service de connexion, l'interface qui affiche les détails de l'utilisateur et la base de données pour les détails, testez ces liens.
  3. Ne vous contentez pas de tester des scénarios de chemin heureux. Les microservices peuvent échouer et il est important de simuler des scénarios de défaillance pour renforcer la résilience de votre système.
  4. Faites de votre mieux pour tester à travers les étapes. L'expérience a prouvé que les testeurs qui utilisent un mélange diversifié de pratiques de test, en commençant par le développement et en progressant à travers des étendues de test plus larges, non seulement augmentent les chances que des bogues se révèlent, mais ils le font efficacement. Cela est particulièrement vrai dans les environnements virtuels complexes où de petites différences existent entre les différentes bibliothèques et où l'architecture matérielle sous-jacente peut produire des résultats imprévus et indésirables malgré la couche de visualisation.
  5. Utilisez « canary testing » sur le nouveau code et testez sur de vrais utilisateurs. Assurez-vous que tout le code est bien instrumenté. Et utilisez également toute la surveillance offerte par votre fournisseur de plateforme. Cela correspond aux tests «décalage à gauche» avec les tests «décalage à droite», car vous testez également «à l'état sauvage».

Démystifier les microservices

Les microservices sont là pour rester. Malheureusement, les organisations ne parviennent pas à récolter les bénéfices de cette approche. Cela se résume à la difficulté de tester les interfaces entre les systèmes distribués (c'est-à-dire les API) pour obtenir la qualité, la sécurité et les performances attendues.

Ce qu'il faut, c'est une approche des tests de microservices qui permette la découverte, la création et l'automatisation des tests de composants. Les technologies habilitantes sont les proxys de messages et la virtualisation des services qui sont étroitement intégrés à un cadre de test d'API riche en fonctionnalités.

Les proxys de messages permettent l'enregistrement du trafic d'API, la surveillance pour découvrir des scénarios et des cas d'utilisation, et le contrôle pour gérer et automatiser des suites de tests d'API. Couplé à la virtualisation des services, le test automatisé des microservices devient une réalité réalisable.

Faites des tests automatisés de microservices une réalité pour votre équipe de développement.