Les microservices fonctionnent bien avec des équipes indépendantes qui ont une responsabilité de bout en bout et utilisent un pipeline CI/CD automatisé. Assurer la qualité des logiciels grâce à des tests de bout en bout peut entrer en conflit avec l'intégration et la publication rapides de composants logiciels. Si un test de bout en bout échoue, les pipelines CI/CD de tous les microservices impliqués sont bloqués jusqu'à ce que le problème provoquant l'échec du test soit résolu.
Lukas Pradel, un consultant sénior, a parlé des défis des tests de bout en bout des microservices à l'Agile Testing Days 2020.
Lukas Pradel a mentionné que la mise en œuvre de tests de bout en bout pour les systèmes basés sur des microservices est un effort plutôt lourd. Techniquement, il ne sera probablement même pas si compliqué de répliquer votre environnement de production à des fins de test. Mais comme les services sont hétérogènes et gérés par différentes équipes, des tâches apparemment innocentes telles que l'alimentation de vos services avec des données de tests cohérentes peuvent être assez difficiles, en particulier lorsque des données en temps réel et des systèmes externes ou hérités entrent en jeu, a déclaré Lukas Pradel.
Lukas Pradel a mentionné que les tests de bout en bout sont notoirement irréguliers, et c'est encore pire dans le cas des systèmes hautement distribués. "Vos tests échoueront souvent pour une myriade de raisons", a déclaré Lukas Pradel, "Il y a tellement de choses qui peuvent mal tourner."
Il y a aussi les problèmes d'identification du coupable et l'impact des cas de test échoués, comme l'explique Lukas Pradel :
Nous utilisons des tests en boîte noire et dans un système distribué, il n'est pas simple de localiser la cause d'une erreur.
Enfin, l'échec des tests de bout en bout bloquera la livraison de tous les microservices impliqués.
Il est facile de sous-estimer l'effort organisationnel consistant à mettre toutes les équipes sur la même longueur d'onde et à établir une communication fiable et efficace, comme l'explique Lukas Pradel :
Qui écrit, implémente et gère vos cas de test de bout en bout ? Les responsabilités ne sont soudainement plus claires car il n'y a plus de frontières naturelles entre services. Dans un scénario réel, vous serez confronté à 50 services ou plus gérés par 15, peut-être 20 équipes, chacune avec ses propres backlogs et priorités.
Il n'y a pas de réponse simple à la question de savoir si vous devez tester votre système de microservices de bout en bout ou non. Décider d'une manière ou d'une autre est bien, mais la décision ne doit pas être prise à la légère et sans connaître les alternatives, comme l'explique Lukas Pradel :
Les tests de bout en bout augmenteront la qualité de votre logiciel et vous aideront à trouver des bogues potentiellement dangereux, mais vous réduirez également considérablement la fréquence de déploiement et le délai d'exécution et voir le couplage entre les services et les équipes. Comme le dit le proverbe, vous ne pouvez pas avoir le beurre et l'argent du beurre.
InfoQ a interviewé Lukas Pradel sur les tests de bout en bout des microservices.
InfoQ : Quelles sont les étapes de tests pour tester une application basée sur des microservices ?
Lukas Pradel : une vieille amie - la pyramide de tests - se révèle une fois de plus d'une grande valeur ici. En commençant par le bas, nous avons nos tests unitaires fiables. Étant donné qu'une architecture de microservices est choisie, en gardant à l'esprit que le but d'une livraison rapide implique que le développement piloté par les tests est donc à peu près obligatoire, il peut y avoir des centaines de tests unitaires et c'est parfaitement bien, car la fiabilité, la vitesse et l'isolation sont les plus élevées au bas de la pyramide de tests.
Ensuite, nous avons des tests d'intégration. Avec ces derniers, nous vérifions si toutes nos unités fonctionnent en conjonction et avec des bases de données et des systèmes de messagerie réels. Il y aura beaucoup moins de tests d'intégration que de tests unitaires et encore moins de cas de tests à mesure que nous gravirons la pyramide.
Ensuite, nous avons parfois des tests contractuels qui garantissent que les interfaces convenues contractuellement entre un fournisseur et un consommateur sont correctement implémentées.
En remontant vers le haut de la pyramide, nous avons des tests d'interface utilisateur au cas où notre microservice aurait une interface utilisateur.
Enfin, tout en haut de la pyramide, nous nous trouvons avec des tests de bout en bout où un cas de test correspond approximativement à un parcours client. Pour ceux-ci, nous appliquons une certaine entrée à l'extrémité du système où les utilisateurs peuvent interagir et inspecter la sortie résultante d'une manière dîte en boîte noire.
Au fur et à mesure que vous grimperez dans la pyramide, le coût, l'effort et la complexité de vos tests augmenteront considérablement, tandis que leur fiabilité, leur vitesse et leur isolation diminueront.
InfoQ : Compte tenu des défis liés aux tests de bout en bout des microservices, quelles sont les alternatives ?
Lukas Pradel : le principal objectif des tests de bout en bout est de minimiser la probabilité de releases de services défectueuses susceptibles d'avoir un impact sur nos utilisateurs. Cependant, nous avons à notre disposition des outils supplémentaires pour atteindre cet objectif. Par exemple, avec les déploiements blue-green, vous disposez de deux environnements de production, dont l'un est votre environnement stable (par exemple bleu) qui reçoit tout le trafic. Lorsque vous déployez un nouveau service, vous le déployez uniquement dans l'environnement vert, puis vous acheminez juste une petite fraction, mais en constante augmentation, du trafic vers l'environnement vert. En cas de problème, vous pouvez rapidement revenir en arrière en redirigeant tout le trafic vers le bleu. Si tout va bien, le vert devient finalement votre nouvel environnement stable et vous recommencez avec le prochain déploiement.
Ensuite, il y a l'option de bascule des fonctionnalités, même si je pense qu'elles devraient être utilisées modérément. De plus, avec tout système distribué, vous devez disposer d'une gestion des performances applicatives (APM) impeccable. Idéalement, vous saurez que quelque chose ne va pas avant vos utilisateurs. Et enfin, il convient de noter que les tests de bout en bout peuvent être effectués en production. Cela résout également le problème de l'échec des tests de bout en bout bloquant les pipelines de livraison de vos microservices.
InfoQ : tu as mentionné que garantir la qualité des logiciels grâce à des tests de bout en bout peut entrer en conflit avec l'intégration et la publication rapides de composants logiciels. Peux-tu développer ?
Lukas Pradel : une architecture microservices est choisie car il y a un fort besoin de délais courts, de déploiements rapides et indépendants des composants et si vous avez la structure organisationnelle pour la backuper - petite équipe autonome avec une responsabilité de bout en bout. Par conséquent, ils sont souvent alimentés par un pipeline CI/CD entièrement automatisé. L'inconvénient est que vous vous retrouvez avec une forte demande de communication et un système socio-technique complexe.
Les tests de bout en bout ruinent la partie ici : dès qu'un échec survient, les pipelines CI/CD de tous les microservices impliqués sont bloqués jusqu'à ce que le problème soit identifié et résolu. Mais cela peut prendre du temps, des heures voire des jours. Du coup, vos équipes sont loin d'être aussi indépendantes que vous le pensiez. En fait, nous avons été confrontés à des «fenêtres de déploiement», c'est-à-dire de longues périodes d'une journée de travail où l'environnement de test de bout en bout était rouge et que personne ne pouvait déployer, interrompu par de petites fenêtres vertes où tout le monde se précipitait pour déployer pour constater que certains tests de bout en bout ont de nouveau échoué pour des raisons totalement indépendantes. Le résultat a été assez frustrant pour toutes les équipes impliquées.
InfoQ : Comment avez-vous résolu ce dilemme, quelle solution avez-vous trouvée ?
Lukas Pradel : avec tout le mal de tête que les tests de bout en bout nous ont donné au fil des ans, il est facile d'oublier qu'ils servent également leur objectif. Ne vous y trompez pas : ils nous ont aidés à identifier de nombreux bogues dans nos microservices. Nous les aurions livrés à nos utilisateurs.
À la fin de la journée, vous devez peser soigneusement vos priorités avec vos parties prenantes; si la qualité du logiciel est primordiale, alors les tests de bout en bout sont obligatoires avec tous leurs inconvénients.
Cependant, si votre besoin de livrer rapidement des fonctionnalités et les avantages des microservices l'emportent sur votre besoin de qualité, par exemple parce que votre produit est situé sur un marché hautement concurrentiel, alors vous pourriez être bien avisé d'envisager les alternatives dont nous avons discuté. Dans notre cas, nos parties prenantes ont opté pour le premier, c'est donc ce que nous avons choisi et nous avons accepté les inconvénients.