Pour faire suite aux articles “La stratégie de test, c'est quoi ?” et “Guide pratique : Bien rédiger un test unitaire pour un code de qualité” nous allons nous intéresser dans cet article aux tests End-to-End, qui permettent de couvrir l’ensemble de l’application, de bout en bout. Nous allons voir ici en quoi ils sont indispensables pour un livrable de qualité mais aussi quelles sont leurs limites.  

 

 

Qu’est-ce qu’un test End-to-End (E2E) 

 

Les tests End-to-End, souvent abrégés en E2E, sont une méthode de test qui simule les interactions d’un utilisateur réel avec une application complète. Contrairement aux tests unitaires ou d'intégration, qui se concentrent sur des parties spécifiques du code, les tests E2E vérifient le bon fonctionnement de l'ensemble du système. L'objectif est de s'assurer que tous les composants d'une application fonctionnent correctement ensemble, en testant des scénarios utilisateur réels à travers les interfaces (UI), les bases de données, les APIs et autres services externes. 

 

 

Avantages de la mise en place de test E2E 

 

Les tests End-to-End offrent de nombreux avantages lorsqu'il s'agit de valider des applications et d’assurer une expérience utilisateur fluide.  

  • Ils permettent une détection efficace des bugs dans des systèmes complexes. En testant l'intégralité du parcours utilisateur, du Front-end au Back-end, les tests E2E identifient les problèmes entre les composants rapidement, 

  • Ils sont essentiels pour garantir la stabilité à chaque livraison. En automatisant les tests de bout en bout, les équipes peuvent s'assurer que les principales fonctionnalités restent intactes après chaque modification du code ou de déploiement/livraison, 

  • Les tests E2E fournissent une assurance qualité utilisateur en validant l'intégralité du parcours utilisateur, tel qu'il serait vécu en conditions réelles. 

 

 

Les défis à surmonter 

 

Bien que les tests End-to-End (E2E) apportent de nombreux avantages, ils représentent également des défis importants.  

L'un des principaux obstacles est le coût en temps et en ressources. Les tests E2E sont souvent plus longs à écrire et à exécuter que les tests unitaires ou d'intégration, car ils vérifient l'ensemble du système et simulent des interactions complexes. Leur mise en place et leur maintenance nécessitent un environnement dédié avec des scripts spécifiques afin de rendre les tests répétables (en phase développement et/ou dans un pipeline CI/CD). 

La complexité des scénarios à automatiser peut également s’avérer problématique. Les parcours utilisateur impliquent souvent des interactions multiples à travers différentes couches (UI, Back-End, bases de données, API externes, etc.), et il peut être difficile d’écrire des tests automatisés pour capturer fidèlement ces interactions sans que les tests ne deviennent trop verbeux ou difficiles à maintenir. 

Enfin, il existe un risque de faux positifs et de faux négatifs : 

  • Un faux positif est un test qui échoue alors que la fonctionnalité est conforme aux attentes. Cela peut s’expliquer, par exemple, par une dépendance externe (comme l’indisponibilité temporaire d’un service tiers) ou par des événements sur l’interface utilisateur qui se produisent trop rapidement., 

  • Un faux négatif est un test qui passe alors qu'une anomalie existe. Cela peut arriver lorsque les assertions ne sont pas correctement définies, ou alors lorsqu’une règle de gestion n’est pas testée dans son intégralité. 

 

Contrairement aux tests unitaires, qui, lorsqu’ils échouent, indiquent une régression dans le code source, les tests E2E quant à eux, exigent que les résultats soient analysés afin de pouvoir remonter les bugs à corriger. 

 

 

Comment bien définir ses tests E2E ? 

  

Il est important de prioriser les tests critiques. Les tests E2E ne doivent pas couvrir tous les scénarios possibles, car cela pourrait ralentir les cycles de développement et de livraison. Il est plus judicieux de se concentrer sur les parcours utilisateur les plus importants, ceux qui ont un impact direct sur l’expérience utilisateur et sur les fonctionnalités critiques de l’application (comme les processus de paiement, de connexion ou de recherche). 

  

Si vous souhaitez automatiser les tests End-to-End dans un pipeline CI/CD, il est préférable de les exécuter à une période donnée, ou avant un déploiement. En effet, ces derniers sont beaucoup plus longs à s’exécuter que les tests unitaires, et nécessitent également plus de ressources. 

  

Une question qui peut également se poser, est de savoir qui doit écrire les tests E2E. Bien que les tests E2E puissent bénéficier de l’expertise des testeurs ou des Business Analystes, ces derniers reposent souvent sur des outils ou une connaissance approfondie du code pour être maitrisés. Les développeurs sont souvent ceux qui écrivent les tests E2E, en collaboration avec les Product Owners, qui aident sur la partie fonctionnelle et la mise en place du scénario. 

 

 

La méthodologie BDD 

Le Behavior-Driven Development (BDD), ou Développement Dirigé par le Comportement, est une approche de développement logiciel qui se concentre sur la collaboration entre les parties prenantes (développeurs, testeurs, et représentants métier) pour définir le comportement d'une application. Dans le contexte des tests End-to-End (E2E), le BDD joue un rôle clé en facilitant la création de tests compréhensibles pour tous les membres de l'équipe, même ceux qui n'ont pas de compétences techniques poussées. 

Le BDD se base sur des spécifications écrites en langage naturel pour décrire le comportement attendu d'une application. Ces spécifications sont ensuite utilisées pour générer des scénarios de tests E2E. L'idée est de rendre les exigences métiers et les tests aussi transparents que possible. 

 

Le langage Gherkin et le BDD 

Un élément central du BDD est l'utilisation du langage Gherkin. Le langage Gherkin a été créé par Aslak Hellesøy, un développeur norvégien, dans le cadre du développement de l'outil Cucumber (Framework de test BDD). 

 

C’est un langage qui permet de décrire les tests sous forme de scénarios. Les scénarios sont structurés en trois parties principales : 

  • Given (étant donné) : pour poser les préconditions du test 

  • When (quand) : pour décrire l'action qui est effectuée 

  • Then (alors) : pour indiquer l'issue attendue ou le résultat 

 

Prenons un exemple d’un scénario pour tester la fonctionnalité de connexion d'un utilisateur : 

  • Feature : Connexion utilisateur   
  • Scenario : Un utilisateur valide se connecte avec succès     
  • Given l'utilisateur est sur la page de connexion     
  • When il entre un identifiant  
  • And un mot de passe valide 
  • Then il est redirigé vers la page d'accueil    
  • And un message de bienvenue apparaît  

 

Ce scénario est lisible et compréhensible aussi bien par un développeur que par un représentant métier. Il permet de spécifier le comportement attendu de la fonctionnalité de connexion. Le test E2E suit les étapes suivantes : vérifier l'affichage de la page de connexion, simuler l'entrée des identifiants, et s'assurer que l'utilisateur est redirigé comme prévu après une connexion réussie et une vérification du message de bienvenue. 

 

Les avantages du Gherkin dans une approche BDD sont : 

  1. Collaboration accrue : Le BDD facilite la collaboration entre les développeurs, les testeurs, et les parties prenantes métiers, car tout le monde peut comprendre les scénarios. Cela permet de s'assurer que les besoins métiers sont bien traduits en tests réels. 

  2. Documentation vivante : Les scénarios Gherkin servent de documentation vivante de l'application. Ils décrivent non seulement comment l'application doit fonctionner, mais sont aussi directement exécutables, ce qui permet de maintenir la documentation et les tests à jour. 

  3. Couverture fonctionnelle complète : Le BDD aide à garantir que tous les comportements critiques de l'application sont couverts, car les scénarios se basent sur les exigences métiers réelles. 

 

Malgré ses avantages, le BDD présente certaines limites : 

  • Maintenance complexe : Les tests BDD, surtout dans des projets complexes, peuvent devenir difficiles à maintenir. Chaque changement dans l'application peut impliquer de nombreux scénarios à réécrire ou à ajuster. 

  • Préparation : les tests E2E nécessitent une préparation minutieuse, que ce soit pour le jeu de données, des interactions avec les IHM ou les appels vers des API internes ou externe. Ils requièrent un environnement dédié, capable d’être détruit et recréé, afin de permettre des exécutions répétées dans des conditions identiques. 

  • Verbosité : Écrire des tests en Gherkin peut parfois devenir verbeux, notamment pour des fonctionnalités complexes. Cela peut alourdir la gestion des tests à long terme. 

  • Apprentissage : Même si le BDD est conçu pour être compréhensible par tous, un temps d’adaptation est nécessaire pour apprendre à structurer les scénarios et organiser les tests de manière appropriée. 

 

 

Les outils et Framework de rédaction de test E2E 

Il existe pléthore d’outils afin de rédiger des tests E2E lisibles et maintenables : 

  • Cucumber : C’est un outil de test BDD (Behavior-Driven Development) qui utilise le langage Gherkin pour écrire des tests E2E. Il est souvent utilisé en combinaison avec Selenium ou d'autres frameworks pour automatiser les tests, 

 

  • Selenium : C’est l'un des outils les plus anciens et les plus utilisés pour l’automatisation des tests Web. Il prend en charge de nombreux langages de programmation (Java, Python, C#, JS, HTML, etc.) et navigateurs. Selenium est très flexible, mais sa configuration et son utilisation peuvent être plus complexes comparé à d’autres produits plus modernes, 

 

  • Cypress : Framework moderne pour l'automatisation des tests E2E. Il se distingue par sa rapidité et sa simplicité d’utilisation. Cypress fonctionne directement dans le navigateur et offre une expérience interactive, ce qui permet de déboguer les tests facilement en temps réel. Il est apprécié pour sa bonne intégration avec les projets JavaScript, en particulier dans le développement front-end. 

 

  • Playwright : Outil open-source développé par Microsoft. Il est similaire à Cypress mais offre la possibilité de tester sur plusieurs navigateurs (Chromium, Firefox, WebKit) et appareils, avec un contrôle plus fin sur les tests, notamment en termes d'authentification ou d'émulation de réseau. Il est particulièrement adapté aux applications complexes qui nécessitent des tests multi-navigateurs. 

 

  • Puppeteer : Bibliothèque Node.js qui permet d'interagir avec des navigateurs basés sur Chromium. Développé par Google, il est surtout utilisé pour tester et automatiser les interactions avec le navigateur Chrome. Moins orienté "test" que d’autres outils comme Cypress ou Playwright. 

 

  • TestCafe : TestCafe est une plateforme de test E2E open-source qui permet d'écrire des tests en JavaScript ou TypeScript. Contrairement à d’autres outils comme Selenium, TestCafe ne nécessite pas de pilotes de navigateur spécifiques et est donc facile à configurer. Il est apprécié pour sa simplicité d’utilisation et son support multi-navigateurs sans configuration supplémentaire. 

 

La liste est longue, d’autres outils sont également utilisés comme Nightwatch.js, Appium (application mobile), Nightwatch.js et WebdriverIO. 

Le choix de l’outil pour les tests E2E dépend principalement de l’environnement de développement et de la complexité de l’application. 

Pour une application Web Moderne (React, Vue, Angular), Cypress s’avère être le choix le plus populaire car il est simple à configurer et offre une expérience interactive et utilise le Javascript nativement. Playwright est également une très bonne option. 

Pour une équipe non technique dans un projet orienté BDD, il est conseillé d’utiliser Cucumber couplé avec Selenium (ou WebDriverIO). 

  

 

Conclusion 

 

Les tests End-to-End représentent un sujet riche et vaste, et ils deviennent rapidement indispensables pour délivrer un produit de qualité. Les défis sont nombreux (coût en ressources, verbosité, prioriser les tests critiques et vitaux), mais les avantages le sont tout autant.  

Dans un contexte agile, où les User Stories sont rédigées en Gherkin (ou s’en approchent), et que l’équipe pratique le BDD, alors il sera plus facile, surtout avec l’aide d’outils modernes comme Cypress ou Playwright, d’établir une stratégie pour mettre en place des tests E2E et produire une application sans faille (ou presque).