À la découverte des tests de bout en bout
Table des matières
Les tests de bout en bout, c’est quoi déjà ?
Problème
Avez-vous déjà essayé de tester le fonctionnement d’une application ou site web que vous avez créé ? Imaginez-vous par exemple devoir aller sur chaque page de votre application et tester manuellement chacune des fonctionnalités. Un clic sur un bouton, l’ajout de contenu, la suppression d’un contenu, l’insertion de données, etc. Pas très enchantant non ?
Maintenant imaginez que vous devez faire cela à chaque nouvelle version de votre application. Ça devient très vite embêtant n’est-ce pas ? Allons un peu plus loin et supposons que vous devez faire cela à chaque fois qu’une nouvelle fonctionnalité est incluse dans l’application ; pour être sûr qu’elle n’interfère pas d’une manière non voulue avec une autre.
Vous devriez commencer déjà à percevoir les limites d’une telle méthode.
Définition
Les tests de bout en bout (end to end testing ou e2e testing en anglais) viennent proposer une manière plus automatisée et efficace de tester le fonctionnement d’une application. La philosophie de ces tests est de simuler un parcours utilisateur sur une application, du début à la fin.
L’idée ici, c’est de recréer des conditions similaires à celles qu’un réel utilisateur rencontrerait en utilisant l’application. Ensuite, de simuler son parcours, puis de rapporter les différents éléments qui ne fonctionnent pas comme prévu.
Méthodologie
Bien que le fonctionnement des tests de bout en bout semble tout banal, il y a une méthodologie à suivre pour les mettre en place afin de les rendre efficaces.
Analyse du fonctionnement de l’application
Pour tester de bout en bout une application, il faut avant savoir comment elle fonctionne, et à quoi s’attendre quand on effectue tel ou tel test.
Par exemple, supposons qu’on veuille tester une application ou un site web comme Google. Quand on est sur la page d’accueil du moteur de recherche et qu’on écrit une expression à rechercher, on est renvoyé sur une nouvelle page avec les résultats de la recherche effectuée.
Voilà un comportement qu’on doit connaître au préalable si la recherche depuis la page d’accueil est une fonctionnalité que l’on veut tester. On espère être renvoyé sur une nouvelle page avec les résultats de la recherche effectuée.
Vous devinez aisément que plus une application a de fonctionnalités, plus les scénarios de tests sont nombreux. C’est donc important de les identifier avant d’écrire tout test.
Une fois les scénarios de tests identifiés, il faut les formuler de manière à ce qu’ils aient un sens et puissent être retranscrits en code. Dans notre exemple avec Google, notre scénario de test peut être le suivant :
- J’ouvre mon navigateur
- Je vais sur la page d’accueil de Google
- J’entre mon expression à rechercher dans la barre de recherche (On n’a pas besoin de cliquer au préalable dans la barre de recherche parce que Google le fait automatiquement)
- J’appuie sur la touche Entrée
- J’espère voir une page avec une liste de résultats de recherche
Il faut ensuite refaire ce processus et écrire les scénarios pour toutes les autres fonctionnalités que nous voulons tester.
Mise en place d’un environnement de test
Une fois les scénarios de tests recensés et écrits, il faut penser ensuite à l’environnement dans lequel les tests vont être exécutés. En général, cet environnement est un navigateur, dans lequel les scénarios vont être simulés. Il faut bien sûr prendre en compte tous les prérequis pour que l’application à tester fonctionne parfaitement dans cet environnement.
A t’on besoin de se connecter à un compte avant d’utiliser l’application ? Certaines données sont elles nécessaires pour tester l’application. Où et comment ces données sont-elles créées ? Comment sont-elles stockées ?
Voilà des questions que l’on peut se poser pendant la mise en place de l’environnement de test ; qui se doit d’être le plus proche possible sinon exact à l’environnement dans lequel un utilisateur réel pourrait se retrouver.
Exécuter et automatiser les tests, reporter les erreurs, améliorer l’application
L’objectif ultime des tests de bout en bout est de s’assurer du bon fonctionnement de l’application, mais aussi d’identifier les comportements prévus de l’application qui ne fonctionnement pas, et y apporter des solutions.
Il faut donc exécuter nos tests, mais aussi automatiser autant que possible ce processus d’exécution. C’est là que ça commence à devenir intéressant. Une fois les tests écrits, vérifiés, on peut maintenant les exécuter automatiquement à des intervalles donnés. Chaque jour, chaque semaine, à chaque fois qu’une nouvelle fonctionnalité est ajoutée, etc.
Ensuite, il faut à côté de ce processus d’automatisation, mettre en place un système de rapports pour avoir une vue d’ensemble sur comment les tests fonctionnent, d’où surviennent les erreurs, etc. Tout ça afin d’identifier au plus vite les éventuels problèmes et les régler.
C’est beau tout ça, mais comment on fait concrètement pour créer des tests de bout en bout ?
En effet, maintenant qu’on sait ce que c’est que les tests de bout en bout, comment ils fonctionnent, on se demande bien comment les créer.
L’univers des tests e2e est très grand. C’est même une discipline à part entière. Il y a donc de nombreuses technologies qui permettent de créer ces tests. Et à côté de nombreux services pour les accompagner, que ce soit pour l’automatisation, le monitoring, les rapports, etc.
Évidemment, le choix d’un ou de plusieurs outils va dépendre du type d’application à tester, des technologies utilisées dans l’application, etc.
Je vais présenter brièvement ici quelques technologies pour mettre en place un système de tests e2e, pour les automatiser et les rapporter. Ces technologies sont principalement celles de que j’ai utilisé dans le cadre de mon travail, ou personnellement pour en apprendre plus sur le sujet.
Jest
Jest est un exécutant de test JavaScript créé et maintenu par Facebook, qui couvre plusieurs aspects des tests d’application, dont les tests de bout en bout. C’est un framework pour projets JavaScript, et il est connu pour être très flexible. Le framework embarque aussi une librairie d’assertion très puissante ; et s’intègre très bien avec la librairie Puppeteer.
J’utilise régulièrement depuis quelques mois dans la suite de tests de bout en bout de WordPress.
C’est également l’outil que j’ai utilisé pour créer la suite de tests de bout en bout de Yoast SEO, l’extension de SEO par excellence pour WordPress.
L’une des choses que j’aime chez ce framework, c’est sa courbe d’apprentissage qui n’est pas très élevée.
CodeceptJS
CodeceptJS est un autre framework JavaScript qui est quant à lui spécifique pour les tests de bout en bout. Il a l’avantage d’embarquer de nombreuses fonctionnalités avancées qui permettent d’interagir avec une application dans un environnement de test.
Autre gros avantage de ce framework, il permet nativement d’utiliser plusieurs outils de contrôle de navigateur, comme Puppeteer, Selenium, Playwright ou encore TestCafe.
Je l’utilise aussi régulièrement sur des projets internes à Yoast.
Cypress
Cypress est plutôt nouveau dans la sphère des outils de tests d’application. Je l’ai d’ailleurs découvert pendant mes recherches pour cet article. En fait, j’ai tout de suite aimé cet outil quand j’ai commencé à en apprendre plus. En termes de philosophie, les créateurs ont pour ambition de faciliter et de rendre accessible l’implémentation des tests automatisés.
Et ça se remarque très vite quand on commence à l’utiliser. Le test runner est très rapidement pris en main et les interfaces d’exécution des tests sont très épurés.
Cypress embarque aussi nativement Chai, la très polyvalente librairie d’assertion pour Node.
Bien sûr, il y a beaucoup d’autres outils qui peuvent être utilisés pour les tests automatisés. Que ce soit des outils de contrôle de navigateur, des librairies/modules d’assertion ou encore des framework tout en un. Encore mieux, il est régulièrement possible d’intégrer ces outils entre eux, afin de tirer profit de chacun de leurs avantages.
