Share this post
Plongeons tête la première dans l'univers des tests de bout en bout pour une application web ! Nous verrons comment écrire des tests parfaits avec Playwright et comment esquiver les pièges qui peuvent surgir. Suivez le guide, c’est parti ! 🚀
Nous allons d’abord planter le décor avec une petite mise en situation qui vous permettra de mieux comprendre pourquoi écrire des tests end-to-end. Si vous voulez passer directement à la pratique, vous pouvez scroller directement jusqu'au paragraphe suivant.
Disons que vous êtes un développeur ou une développeuse en train de travailler sur une application web révolutionnaire de To-do List.
Vous codez votre première fonctionnalité qui permet de créer des To-dos, vous la testez en local, elle fonctionne bien, vous la déployez sur le serveur qui héberge votre appli.
Votre application rencontre un grand succès et des milliers d’utilisateurs la visitent tous les jours !
Vous n’avez pas envie de les décevoir et décidez de coder une deuxième fonctionnalité permettant de modifier les To-dos, vous la testez en local, elle fonctionne bien, donc vous la déployez sur le serveur.
Mais là, catastrophe ! Le nombre d’utilisateurs baisse considérablement de jour en jour. Vous regardez les avis et vous vous rendez compte qu’ils se plaignent de ne plus pouvoir créer de To-dos.
.gif)
En effet, lors du déploiement de la deuxième fonctionnalité, vous avez cassé la première fonctionnalité, vous avez introduit une régression.
Vous choisissez d'intégrer une troisième fonctionnalité pour supprimer les To-dos. Après avoir codé cette nouvelle fonctionnalité, vous effectuez des tests manuels sur les trois fonctionnalités existantes pour ne pas introduire de régression. Une fois confirmé que tout fonctionne correctement, vous déployez votre code.
Le temps passe et les fonctionnalités s’additionnent, vous prenez un temps fou à tester à la main toutes les anciennes fonctionnalités avant d’en introduire une nouvelle. Il vous arrive de temps en temps de passer à côté de régressions car vous n’avez pas le temps de tester tous les cas.
Il est temps d’automatiser tout ça ! Ajoutons des tests end-to-end (ou de bout en bout) à votre application afin de pouvoir tester rapidement tous les parcours critiques de votre appli. En plus, cela vous permettra d’ajouter des nouvelles fonctionnalités sans avoir peur de casser les fonctionnalités existantes !
.gif)
Les tests end-to-end (ou de bout en bout) sont des tests qui simulent les actions de l'utilisateur sur l'interface utilisateur. Ils sont très simples à écrire et permettent de gagner du temps car ils vous évitent de tester votre app manuellement.
Les tests end-to-end se situent en haut de la pyramide de tests et représentent les tests les plus réalistes. Cependant, ils sont aussi les plus lents à exécuter et nécessitent un environnement complet, cela peut demander plus de ressources et être plus coûteux.
.png)
Dans le cas de l’application de To-do list, il faudrait tester la création d’une To-do. Le test doit alors :
Ensuite, le test affirme (assert en anglais) qu’une checkbox portant le nom de la To-do est visible à l’écran.
Comme exemple d’application, nous utiliserons une application simple de To-do, déjà codée.
Vous trouverez son dépôt Github ci-dessous :
Repo Github: https://github.com/MatheusCavini/ReactJS-ToDoList.git
Vous pouvez néanmoins utiliser n’importe quelle autre application, comme la vôtre par exemple.
Clonez le dépôt avec git clone https://github.com/MatheusCavini/ReactJS-ToDoList.git, naviguez dans le dossier créé avec cd ReactJS-ToDoList, installez les dépendances avec npm i, puis lancez l’app avec npm start et enfin testez quelques fonctionnalités manuellement si vous le souhaitez.
Vous devriez arriver sur une page qui ressemble à ça :
.png)
Nous aurons besoin d’installer Playwright. En effet, c’est la librairie de tests que nous utiliserons pour écrire nos tests end-to-end.
Exécutez cette commande à la racine du projet afin d’y installer Playwright.
On vous demandera sûrement dans quel dossier vous voulez voir apparaître vos tests, je vous conseille de laisser l’option par défaut “tests” :
.png)
On vous demandera également si vous souhaitez ajouter un workflow Github Actions, répondez non (N).Cependant, on a bien envie d’installer les navigateurs Playwright qui nous permettront de lancer les tests end-to-end sur l’application (Y).
.png)
Des fichiers ont été créés après l’exécution de la commande :
.png)
- Le premier fichier est un fichier de configuration, vous le modifierez si vous avez besoin de configurations avancées de Playwright telles que l’exécution de tests en parallèle, la personnalisation du rapport de tests, etc…
- Les deux autres fichiers sont des fichiers d’exemples de Playwright, vous pouvez les supprimer car nous allons écrire nos tests de zéro !
Les tests Playwright suivent un schéma simple :
Playwright utilise des localisateurs (locators en anglais) afin de récupérer des éléments de la page. Il est possible de récupérer un élément de différentes manières et plutôt que d’utiliser la fonction page.locator() ou page.$() en lui passant un sélecteur du DOM, il est préférable d’utiliser les fonctions prédéfinies de Playwright :
button, checkbox, dialog, …)titledata-testidPar exemple, pour récupérer le bouton qui contient le label “Valider” :
💡Bonne pratique : donner la priorité aux localisateurs visibles par l'utilisateur, tels que le texte ou le rôle d’accessibilité, plutôt que d'utiliser des sélecteurs JQuery qui sont liés à l'implémentation et risquent de se briser en cas de modification de la page.
Après avoir récupéré un élément, on peut exécuter des actions dessus avec les fonctions de Playwright. Les actions recommandées sont :
Si on veut remplir un champ avec le texte “Hello”, on fera :
Si on veut cocher une case à cocher, on fera :
Si on veut sélectionner une option dans une liste déroulante, on fera :
Il existe de nombreuses affirmations pour différentes conditions :
À noter que tous les contraires sont possibles en ajoutant un .not devant chacune des méthodes
On veut également pouvoir affirmer (assert en anglais) que quelque chose se passe bien comme prévu. Par exemple, après avoir cliqué sur le bouton, on s’attend à ce qu’une checkbox portant le label de notre To-do soit visible à l’écran. Pour tester ça, nous ferons :
Dans ce snippet de code, on clique sur le bouton “Valider”, puis on affirme que la checkbox portant le label “Nouvelle tâche” ne soit pas cochée (normal, nous venons de la créer !).Si l’élément portant le nom “Nouvelle tâche” n’est pas visible à l’écran, Playwright renverra une erreur explicite nous permettant de résoudre le problème, si la checkbox est cochée au lieu d’être décochée, Playwright nous renverra aussi une erreur explicite !
📝 Essayez d’écrire un test end-to-end dans le dossier tests qui teste la création de To-do.Il devra :
[Indice 1] : Avez-vous pensé à naviguer vers l’application avant d’exécuter votre test ? La méthode goto sert justement à ça
[Indice 2] : Il existe un localisateur pour localiser les éléments par placeholder : getByPlaceholder
[Indice 3] : Nous pouvons utiliser getByRole pour accéder aux boutons
[Indice 4] : Sur cette application, la façon de localiser la liste déroulante des catégories serait avec un getByRole, mais personnellement, je préfère modifier le composant pour y ajouter un attribut arial-label et pouvoir le localiser avec un getByLabel. On améliore ainsi l’accessibilité de l’application.
[SPOILER] : La solution
Pour cela, il vous suffit d’exécuter cette commande à la racine du projet :
Les tests doivent passer et vous devriez voir cette sortie dans la console :
.png)
Si vous deviez retenir trois choses de cet article, vous retiendriez :
Pour voir ce que Playwright fait en temps réel sur l’application, deux possibilités :
.png)
Que vos tests soient tous passés ou non, Playwright génère un rapport HTML disponible dans le dossier playwright-report.
Ce rapport contient de nombreuses informations utiles pour débugger les tests qui ont échoué.
Il liste les tests, et si on clique sur un test, il affiche les actions effectuées et l’endroit où le test a échoué.
Le rapport affiche même le Trace Viewer qui permet d’afficher l’écran du navigateur pour mieux comprendre pourquoi le test a échoué. Il contient des outils développeurs avec les onglets Console, Réseau et Source.
Vous pouvez modifier la configuration Playwright pour modifier les options de sa génération.
Pour le visualiser correctement, utilisez la commande suivante :
Un serveur web se lancera alors sur le port 9223 et vous accèderez à un page comme celle-ci :
.png)
Un serveur web se lancera alors sur le port 9223 et vous accèderez à un page comme celle-ci :
.png)
À prendre quand même avec des pincettes, n’oubliez pas de repasser derrière, la génération de code automatique n’est jamais parfaite !
Il existe de nombreuses librairies de tests mais j’ai choisi de vous parler de Playwright pour plusieurs raisons :
Si les utilisateurs de votre application utilisent principalement un navigateur particulier, comme Chrome, et que les développeurs de votre équipe travaillent avec JavaScript, Cypress peut être une meilleure alternative en offrant un environnement de test plus ciblé.
Documentation de Playwright : https://playwright.dev/docs/intro
Voici un article sur Cypress : https://www.sipios.com/blog-posts/how-to-create-readable-end-to-end-tests-with-cypress-and-cucumber
C’est bon, vous êtes fin prêts et êtes devenus un hero en tests end-to-end ! J’espère que l’article vous aura servi et que vous aurez pris du plaisir à le lire !
N’hésitez pas à réagir à l’article, à le commenter ou à me contacter si vous avez des questions !
