Les microservices sont des applications distribuées déployées dans différents environnements et pourraient être développées dans différents langages de programmation ayant différentes bases de données avec trop de communications internes et externes. Par conséquent, une architecture de microservices dépend de plusieurs applications interdépendantes pour ses fonctionnalités de bout en bout. Cette architecture de microservices complexe nécessite une stratégie de test systématique pour garantir des tests de bout en bout (E2E) pour tout cas d’utilisation donné. Dans ce blog, nous discuterons de certaines des stratégies de test d’automatisation les plus adoptées pour les microservices, et pour ce faire, nous utiliserons l’approche du triangle de test.
Triangle de test
C’est une façon moderne de tester les microservices avec une approche ascendante, qui fait également partie de la méthodologie de test « Shift-left » (la méthode de test « shift-left » pousse les tests vers les premières étapes du développement logiciel. En testant tôt et souvent, vous pouvez réduire le nombre de bogues et augmenter la qualité du code.). L’objectif d’avoir plusieurs couches empilées de la pyramide de test suivante pour les microservices est d’identifier différents types de problèmes au début des niveaux de test. Donc, au final, vous aurez très peu de problèmes de production. Chaque type de test se concentre sur une couche différente du système logiciel global et vérifie les résultats attendus. Pour une application de microservices distribués, les tests peuvent être organisés selon les couches suivantes à l’aide d’une approche ascendante :
Le triangle de test est basé sur ces cinq principes :
1. Tests unitaires
C’est le point de départ et le test de la boîte blanche de niveau 1 dans l’approche ascendante. De plus, il teste une petite unité de fonctionnalité de code source de microservices. Il vérifie le comportement des méthodes ou des fonctions du code source à l’intérieur d’un microservice en supprimant et en se moquant des modules dépendants et des données de test. Les développeurs d’applications écrivent des cas de test unitaires pour une petite unité de code (fonctions/méthodes indépendantes) en utilisant différentes données de test et en analysant la sortie attendue indépendamment sans impact sur les autres parties du code. C’est un élément essentiel de l’approche de test « shift-left », où les problèmes sont identifiés dans la phase de démarrage au niveau de la méthode des microservices. Ce test doit être effectué de manière approfondie avec une couverture de code supérieure à environ 90 %. Cela réduira les risques de bogues potentiels dans les phases ultérieures.
2. Test des composants
C’est le test de niveau 2 du Triangle de test qui suit les tests unitaires. Ces tests visent à tester des fonctionnalités et des API de microservices entiers indépendamment de manière isolée pour un microservice individuel. En écrivant des tests de composants pour la couche de microservices hautement granulaire, le comportement de l’API est piloté par des tests du point de vue du client ou du consommateur. Les tests de composants testeront l’interaction entre les API/services de microservices avec la base de données, les files d’attente de messagerie et les services sortants externes et tiers, le tout comme une seule unité.
Il teste une petite partie de l’ensemble du système. Par exemple, dans les tests de composants, les microservices dépendants et les réponses de la base de données sont simulés ou tronqués. Dans cette approche de test, toutes les API de microservices sont testées avec plusieurs ensembles de données de test.
3. Tests contractuels
L’approche de test de niveau 3 vérifie les contrats convenus entre différents microservices pilotés par domaine. Il existe des contrats définis avant le développement de microservices dans l’API/l’interface, concevant quelle devrait être la réponse à la demande ou à la requête client donnée. Si des changements surviennent, le contrat doit être réexaminé et révisé. Par exemple, si de nouvelles modifications de fonctionnalités sont déployées, elles doivent être exposées avec une demande d’API de version /v2 distincte, et nous devons nous assurer que l’ancienne version /v1 prend toujours en charge les demandes des clients pour la rétrocompatibilité.
Il teste une petite partie de l’intégration, comme :
- Entre microservice et ses bases de données connectées.
- Appels d’API entre deux microservices.
4. Tests d’intégration
Il s’agit de tests de niveau 4 qui vérifient la fonctionnalité de bout en bout. Il s’agit du prochain niveau de test de contrat, où les tests d’intégration sont utilisés pour tester et vérifier une fonctionnalité entière en testant tous les microservices associés.
Selon Martin Fowlerun test d’intégration exerce des voies de communication à travers le sous-système pour vérifier les hypothèses incorrectes que chaque module a sur la façon d’interagir avec ses pairs.
Il teste une plus grande partie du système, principalement les microservices exposant leurs services avec l’API. Par exemple:
- Fonctionnalité de connexion, qui implique plusieurs interactions de microservices.
- Il teste les interactions pour l’API de microservices et les composants de concentrateur pilotés par les événements pour une fonctionnalité donnée.
5. Test de bout en bout (E2E)
Il s’agit de l’approche de test finale et de niveau 5 dans le triangle de test, et il s’agit d’un test de boîte noire d’utilisabilité de bout en bout. Il vérifie que l’ensemble du système dans son ensemble répond aux objectifs fonctionnels de l’entreprise d’un utilisateur ou d’un client, ou du point de vue d’un client. Les tests E2E sont effectués sur le front-end externe (interface utilisateur (UI)) ou les appels du client API à l’aide des clients REST. Il est effectué sur différents microservices distribués et applications SPA (Single Page Apps)/MFE (Micro Frontends). Il couvre les tests de l’interface utilisateur, des microservices principaux, des bases de données et de leurs composants internes/externes.
Défis des tests de microservices
De nombreuses organisations ont déjà adopté la transformation numérique, qui utilise une architecture de microservices. Les organisations informatiques ont du mal à tester les applications de microservices en raison de leur nature distribuée. Nous discuterons des défis importants et des solutions proposées par certains des experts de l’industrie :
Plusieurs équipes de microservices agiles
L’intercommunication entre plusieurs équipes de développement et de test de microservices agiles est très longue et difficile. Parfois, les équipes travaillent en silos, ne partageant pas suffisamment de détails techniques/non techniques, ce qui entraîne des lacunes de communication.
Solutions : tester l’intégration de triangle et les tests E2E peuvent aider à relever le défi ci-dessus en testant des microservices dépendants, qui sont développés par différentes équipes de développement.
Défis liés aux tests d’intégration de microservices
Les tests de tous les microservices ne se font pas en parallèle. Les tests d’intégration de bout en bout de microservices interdépendants sont un cauchemar ; en réalité, ces microservices peuvent ne pas être prêts à être testés dans un environnement de test. Chaque microservice aura son propre mécanisme de sécurité et ses propres données de test. Trouver le basculement d’autres microservices lorsqu’ils dépendent les uns des autres est une tâche ardue.
Solutions : tester les tests d’intégration de triangle aide ici en testant les API de microservices dépendantes.
Exigences commerciales et défis de changement de conception
Les changements fréquents dans les exigences commerciales et techniques de la méthodologie de développement agile entraînent une augmentation de la complexité et des efforts de test. Cela augmente les coûts de développement et de test.
Solutions : Le triangle de test fournit un processus systématique efficace, étape par étape, qui réduit les complexités, les coûts opérationnels et les efforts de test grâce à des tests entièrement automatisés.
Tester les défis de la base de données
Les bases de données ont différents types (SQL/NoSQL comme Redis, MongoDB, Cassandra, etc.), qui ont des structures différentes. Ces types de données structurées et non structurées peuvent être combinés pour répondre à des besoins commerciaux particuliers. Par exemple, chaque base de données a un type différent de données de test dans le développement de microservices distribués. Il est intimidant de maintenir différents types de données de test pour différentes bases de données.
Solutions : Le triangle de test fournit un BDD (Behavioral Driven Design) automatisé où nous pouvons transmettre des données de test dynamiques ; et la méthode TDM (Test Data Management), qui résout les problèmes de base de données de test en gérant différents types/formats de données de test.
Conclusion
Le triangle de test fournit d’excellentes techniques de test pour résoudre les défis associés aux microservices. Nous devons choisir ces techniques de test systématiques dans une perspective de complexité moindre, de test plus rapide, de délai de mise sur le marché, de coût de test et d’atténuation des risques avant de passer en production. Cette stratégie de test est nécessaire pour les microservices afin d’éviter de véritables problèmes de production. Cela garantit que les cas de test doivent couvrir les tests E2E fonctionnels et non fonctionnels de bout en bout pour l’interface utilisateur, le backend, les bases de données et différents environnements de mise en scène PROD et non PROD pour des versions de produits fiables.
Nous avons vu les microservices introduire de nombreux défis de test qui peuvent être résolus avec une approche étape par étape (de bas en haut) fournie en testant des techniques de triangle.
Il s’agit d’une stratégie de test cloud native moderne pour tester les microservices sur un cloud. Il trouve et corrige un maximum de bogues pendant la phase de test jusqu’à ce qu’il atteigne le niveau le plus élevé (niveau le plus élevé dans le triangle), qui est le test E2E.
Conseils: De nombreuses organisations informatiques ont commencé à suivre la culture « Shift-left » et ont commencé à utiliser une culture de test, en particulier dans les situations où il est important d’identifier et de corriger les bogues tôt.