Tests E2E : Un tutoriel et un guide architectural
Les tests E2E (End-to-end) aident à valider les flux les plus importants de votre application, comme les demandes de connexion des utilisateurs. Pour le développement front-end, les tests E2E permettent de vérifier si l’interface utilisateur correcte a été présentée. Pour le développement back-end, les tests E2E aident à vérifier si un flux important dans vos services back-end renvoie la sortie attendue.
Ce post vous présentera les tests E2E et vous donnera des conseils exploitables. Nous expliquerons également comment écrire des tests réutilisables afin qu’ils puissent être utilisés pour créer des tests E2E plus facilement. Comme vous le savez peut-être, les tests E2E sont souvent une frustration majeure pour les développeurs car ils nécessitent beaucoup d’efforts pour écrire, exécuter et maintenir.
D’abord, regardons où les tests E2E se situent dans la pyramide des tests logiciels.
La place des tests E2E dans la pyramide des tests
Lorsque l’on regarde la pyramide des tests, on trouve quatre types de tests principaux pour nous aider à garantir la qualité du code :
- Les tests E2E aident à vérifier les chemins à haute valeur ajoutée dans votre application. En d’autres termes, ils aident à vérifier les user stories car elles représentent souvent des flux dans votre application.
- Les tests d’intégration aident à vérifier l’intégration de plusieurs fonctions ou composants. Les tests d’intégration peuvent vous dire si votre code fonctionne de manière cohésive avec d’autres fonctions.
- Les tests unitaires aident à vérifier la logique métier des fonctions. Les tests unitaires sont la forme la plus basique de test, et ils assurent que la logique métier est correcte.
- Enfin, nous ne pouvons pas oublier l’analyse statique ou les tests statiques. Les tests statiques permettent de trouver les coquilles ou les erreurs de type.
Selon cette pyramide, la plupart des tests devraient être des tests unitaires, avec moins de tests d’intégration et encore moins de tests E2E. Cependant, il est toujours important de vérifier les flux dans votre application. Les tests E2E sont difficiles à maintenir et demandent beaucoup d’efforts. Par conséquent, ne vérifiez que les flux les plus importants avec des tests E2E. D’autres types de tests tels que les tests d’intégration et les tests unitaires devraient déjà vous donner une confiance suffisante dans votre base de code.
Différentes stratégies de tests E2E
Laissez-moi vous dire que différentes stratégies existent. Nous pouvons choisir entre les tests E2E horizontaux et les tests E2E verticaux. Ces deux stratégies méritent d’être explorées car elles vous permettent de tester différents scénarios. Apprenons ce que fait chaque stratégie.
Stratégie #1 : Test vertical de bout en bout
Cette stratégie se concentre sur le test de toutes les couches de la pyramide de test. Elle comprend des tests unitaires, des tests d’intégration et des tests d’interface utilisateur. Votre objectif est de tester un composant à un niveau granulaire à l’aide de tests unitaires, de tester le comportement d’un composant lorsqu’il interagit avec d’autres composants à l’aide de tests d’intégration et, enfin, de vérifier le comportement du composant lorsque les utilisateurs interagissent via l’interface utilisateur.
Le plus souvent, vous voulez utiliser un pipeline d’intégration continue pour automatiser ces tests pour chaque commit de code ou demande de pull.
Stratégie #2 : Tests horizontaux de bout en bout
Les tests horizontaux E2E se concentrent sur la vérification d’un flux utilisateur complet. Voici un exemple de flux pour une boutique en ligne :
- Ouvrir la page du produit
- Sélectionner la taille du produit
- Ajouter le produit au panier
- Aller à la caisse
- Compléter l’adresse et les informations de paiement
- Compléter le paiement
- Afficher l’écran de confirmation d’achat
Ici, nous voulons vérifier chaque transaction du flux utilisateur. Souvent, ce type de test vérifie l’interaction entre différentes applications et vérifie les changements d’état pour ces applications.
Notez que ces types de tests sont coûteux à écrire. Il faut pas mal de temps pour définir les flux d’utilisateurs et écrire ces tests. Par conséquent, essayez de vous concentrer sur les chemins de transaction critiques pour votre application.
Cependant, assurez-vous de tester ces flux d’utilisateurs critiques pour différentes conditions. Cette stratégie vous permet d’obtenir une image complète de la robustesse du flux utilisateur. Ces conditions comprennent :
- Des scénarios de timing complexes : Par exemple, un billet de concert n’est disponible que pendant 15 minutes.
- Des entrées de données différentes ou des données manquantes.
- Des ruptures de flux : Un utilisateur décide de quitter la page de caisse pour consulter une autre page de produit. Par exemple, nous devons vérifier si le composant sauvegarde l’état de la caisse.
Puis, apprenons quand écrire des tests E2E.
Quand écrire des tests E2E
Vous ne savez peut-être pas que les tests E2E sont des tests coûteux à exécuter dans votre pipeline d’intégration continue. Ils nécessitent souvent beaucoup de préparation, comme la création d’une base de données qui imite les données de production. De plus, ils représentent parfois des flux qui prennent du temps dans votre application. Par conséquent, ils peuvent être lents et nécessiter plus de ressources pour être exécutés.
Utilisez les tests E2E pour vérifier les flux les plus importants de votre application. Voici quelques exemples de flux à forte valeur ajoutée :
- Connexion et déconnexion
- Enregistrer un nouvel utilisateur
- Ajouter un article au panier
- Changer votre mot de passe
- Tout autre flux important lié à votre service
N’oubliez cependant pas de vérifier la logique métier que vous écrivez avec des tests unitaires et d’intégration. La combinaison des tests unitaires et d’intégration devrait vous donner une grande confiance dans la qualité de votre code. Les tests E2E vous aident à augmenter cette confiance pour les chemins critiques.
Voici quelques conseils actionnables pour écrire des tests E2E.
Conseils pour écrire des tests E2E
Focus sur l’écriture de tests réutilisables
Le premier et le plus important conseil est d’écrire de petits tests et composants indépendants et réutilisables. Cela vous permet d’enchaîner plusieurs petits composants pour créer plus facilement des flux utilisateur complets de bout en bout. Au lieu d’écrire beaucoup de composants personnalisés uniquement pour être utilisés par les tests E2E, concentrez-vous sur l’écriture de composants réutilisables.
Écrire de petits composants indépendants aide à la réutilisation du code et réduit le temps de dépannage des erreurs. En outre, il est plus facile de mettre à jour les petits composants lorsque les fonctionnalités ou les flux d’utilisateurs changent.
Toujours considérer la raison d’écrire un test E2E
Lorsque vous voulez couvrir un flux particulier avec un test E2E, considérez s’il vaut la peine d’être couvert. Ne testez que les flux d’utilisateurs de grande valeur avec des tests E2E. Par exemple, vous ne devriez pas tester si un message d’erreur s’affiche lorsqu’un utilisateur saisit une adresse électronique incorrecte. Il s’agit d’un cas d’utilisation beaucoup trop simple qui ne convient pas à un test E2E. Cette exigence peut simplement être testée avec un test unitaire.
D’autre part, il vaut la peine de tester si la page de connexion vous redirige vers la bonne page d’application après avoir réussi à vous connecter. C’est un flux précieux pour que vos utilisateurs puissent utiliser l’application. En bref, considérez toujours la raison pour laquelle vous écrivez un test E2E.
Les tests E2E ne devraient pas dépendre des détails d’implémentation
Vous ne voulez pas mettre à jour les tests E2E chaque fois que vous changez les détails d’implémentation pour un certain flux. Par conséquent, vous voulez écrire des composants qui vous permettent d’abstraire les détails d’implémentation. Les tests E2E deviennent beaucoup plus faciles à maintenir, et plus amusants à écrire, lorsque les détails d’implémentation sont cachés dans les composants. En bref, les tests E2E devraient être indépendants des détails d’implémentation.
Puis, regardons les pièges des tests E2E.
Pièges des tests E2E
Voici une liste des pièges communs associés aux tests E2E :
- Les tests E2E ne devraient pas essayer de tester autant que possible en une seule fois. Souvent, les développeurs écrivent d’énormes tests E2E qui vérifient chaque aspect du flux utilisateur. Gardez les choses simples et vérifiez les aspects les plus importants de votre flux utilisateur. Par exemple, pour un flux de connexion, vous devez seulement vérifier si l’utilisateur a été redirigé vers la page de l’application. Cela facilitera la maintenance et la mise à jour des tests E2E pour les développeurs.
- Lorsqu’un test E2E échoue, il peut être difficile de trouver la cause exacte de l’échec. Cependant, vous pouvez réduire les efforts de débogage nécessaires en couvrant votre logique métier avec des tests unitaires et d’intégration. Certains outils fournissent également une bonne analyse de la cause première, y compris des captures d’écran et des journaux de console des étapes de test échouées, ce qui peut réduire le temps de dépannage.
- Les tests E2E nécessitent un temps considérable dans votre pipeline d’intégration continue (CI). Ils peuvent bloquer votre pipeline CI, ce qui ralentit le développement global. Cela signifie que vous devrez peut-être investir dans votre pipeline CI pour avoir quelques pipelines supplémentaires pour l’exécution des tests.
- Les tests E2E sont un effort continu. Chaque fois qu’une nouvelle fonctionnalité est ajoutée ou qu’une ancienne fonctionnalité change, il est probable que vous deviez mettre à jour vos tests E2E. Cependant, nous pouvons réduire cet effort en écrivant des composants réutilisables qui abstraient les détails d’implémentation. En outre, certains outils utilisent l’IA pour aider à adapter les tests lorsque le code change, réduisant ainsi la maintenance des tests.
Maintenant, jetons un bref coup d’œil aux différences entre les tests système et les tests E2E.
Tests système vs. tests E2E – Quelle est la différence ?
Donc, quelle est la différence entre les tests système et les tests E2E ? Les tests système se concentrent sur la validation des exigences fonctionnelles comme non fonctionnelles. Souvent, il est réalisé par une équipe externe qui traite l’application comme une boîte noire. En d’autres termes, ils ne savent rien du fonctionnement de l’application, à l’exception des exigences auxquelles elle doit répondre.
Cependant, cette forme de test est souvent confondue avec les tests E2E, car le test système est une forme de test E2E. Bien que, les tests système vérifient beaucoup plus que les tests E2E. Par exemple, le test système mesure l’évolutivité, la performance ou la fiabilité. Alors que les tests E2E se concentrent sur l’achèvement correct des flux d’utilisateurs.
Enfin, résumons les apprentissages de cet article.
Conclusion sur E2E
Les tests de bout en bout sont assez puissants car ils aident à valider les flux d’utilisateurs de grande valeur ou les user stories. Ils aident à garantir la qualité de votre application.
Cependant, l’écriture et la maintenance des tests E2E peuvent demander beaucoup de temps et d’efforts. Il est possible de réduire cet effort en écrivant de petits composants réutilisables qui font abstraction des détails d’implémentation. Certains outils permettent également de créer des tests plus résistants en utilisant l’IA ou plusieurs attributs pour identifier chaque élément. Par conséquent, il n’est pas nécessaire de mettre à jour les tests E2E chaque fois que les détails d’implémentation changent pour les flux d’utilisateurs à forte valeur ajoutée. En outre, les composants réutilisables vous permettent d’enchaîner ces composants pour créer facilement des flux de tests E2E.
Les tests E2E doivent couvrir les flux les plus importants de votre application. Ils testent les flux que vos utilisateurs et clients suivent pour obtenir de la valeur de votre application. S’ils ne peuvent pas se connecter ou ajouter un article à un panier, ils quitteront (s’ils le peuvent) ou appelleront le support s’ils sont forcés d’utiliser votre application. Par exemple, vous voulez couvrir le flux de connexion et de déconnexion, mais vous êtes moins intéressé par la vérification d’un message d’erreur après la saisie d’une mauvaise adresse e-mail.
En fin de compte, les tests E2E doivent être amusants à écrire. Ils ne devraient pas nécessiter beaucoup de temps et d’efforts pour écrire et maintenir. Gardez les tests E2E simples et concentrez-vous sur les composants réutilisables, et vous verrez d’excellents résultats !
Ce billet a été écrit par Michiel Mulders. Michiel est un développeur blockchain passionné qui aime écrire du contenu technique. À côté de cela, il aime apprendre sur le marketing, la psychologie UX et l’entrepreneuriat. Quand il n’écrit pas, il est probablement en train de déguster une bière belge !
.