Dans cet article vous découvrirez notre retour d’expérience sur l’utilisation de deux outils pour l’implémentation de tests de bout-en-bout (End-to-end) : Cypress vs Puppeteer. Ce type de test permet de s’assurer du bon fonctionnement d’une application en automatisant les navigateurs afin de dérouler des scénarios types d’actions effectuées par un utilisateur.

• Puppeteer est un outil développé par Google qui permet de contrôler une instance du navigateur Chrome avec ou sans interface utilisateur, grâce à l’API Dev Tools.
• Cypress est un outil open-source développé par l’entreprise du même nom. Il propose également des services complémentaires payants au-delà d’un certain seuil d’utilisation.

Le Test

Pour évaluer ces outils, nous avons implémenté un test end-to-end relativement complexe avec chacun d’entre eux. Ce test comprend 89 étapes, il consiste principalement en une série de clics, de saisies clavier, et de drag & drop (glisser-déposer). Aucune des deux solutions ne propose nativement de fonctionnalité drag & drop, nous avons donc appliqué la même solution pour les deux outils : créer des événements en JavaScript et utiliser dispatchEvent).

Les résultats

Réactivité : Égalité

Cypress et Puppeteer ont tous les deux permis de réaliser le test en environ 35 secondes. Il semble donc qu’aucun d’entre eux ne dispose d’un avantage concret à ce niveau.

Fiabilité : Cypress

Au fil des tests, il est rapidement devenu évident que Puppeteer se montrait bien moins fiable. Parfois les clics ne fonctionnaient pas et les tests se retrouvaient alors bloqués. Cela se produisait alors que les cibles étaient pourtant présentes à l’écran au moment des tentatives de clics. Il s’agit probablement d’un bug dans Puppeteer mais nous n’avons pas eu le temps d’en rechercher la cause de manière approfondie.

Outillage : Cypress

Cypress a été conçu spécialement pour les tests end-to-end (E2E) et cela se ressent. Pour parvenir à implémenter les mêmes tests avec Puppeteer, nous avons dû ajouter beaucoup plus de fonctionnalités par nous-mêmes. L’une des différences fondamentales entre ces deux solutions est que Puppeteer n’est pas particulièrement conçu pour gérer des tests. Ce n’est pas un outil de test E2E mais avant tout un outil d’automatisation de navigateur. Afin de l’utiliser pour les tests, nous avons dû utiliser jest-puppeteer, ce qui a fonctionné relativement bien. Cypress inclut nativement le framework de test mocha. En plus d’utiliser un framework de test, Cypress ajoute une couche autour de l’application testée. Celle-ci inclut :

• La journalisation des commandes (log)
• Une fonctionnalité pour debugger les tests
• Un outil d’aide à la recherche de sélecteurs pour les éléments
• Des outils pour inspecter le DOM à tout moment du test
• Une vue de l’application qui est automatiquement ajustée à l’espace disponible pour le debugging, en parallèle de l’usage d’une résolution donnée pour le test

Cypress supervise également les changements apportés aux tests et relance ceux-ci pendant que vous travaillez : les tests et les développements se font simultanément. Etant donné que Cypress restore soigneusement le navigateur à son état d’origine entre les tests, c’est une énorme avancée en termes de workflow, qui permet de voir quasiment instantanément le test que vous éditez se mettre à jour en incluant vos nouveaux changements.

API : Égalité

L’API de Cypress fournit des fonctionnalités plus utiles pour les tests E2E, comme les assertions, qui ne sont pas non-plus comprises avec Puppeteer. Ce que nous n’avons pas apprécié avec l’API de Cypress est qu’elle utilise un planificateur personnalisé pour ses commandes. Ainsi, (‘.button’).click() peut ressembler à une commande synchrone mais c’est en réalité une demande de planification d’instructions dans Cypress qui s’exécutera ultérieurement. Ce n’est pas intuitif et en conséquence, en comparaison avec Puppeteer, la compréhension du flux des tests de Cypress est sensiblement plus difficile. Le choix de Cypress de ne pas utiliser async/await peut s’expliquer par des raisons d’architecture mais nous espérons que ce problème finira par être résolu. A sa décharge, nous trouvons que cette approche a pour avantage de restreindre la façon dont peuvent être rédigés les tests, les rendant plus déterministes, ce qui est généralement plus efficace.

Conclusion

Nous avons largement préféré utiliser Cypress. Il inclut de meilleurs outils et s’est montré plus fiable pour nos cas d’utilisation.