
Envoyé par
randriano
Merci pour l'info Marco46
On aimerait lire un "tutoriel pour les nuls" sur ce nouvel outil pour mieux piger son atout: du genre de Selenium à Cypress, qu'est-ce qui est amélioré?
Il faut que je passe plus de temps à tester la bête mais là justement dans le cadre du taf j'y passe du temps donc en bout de ligne je ferai au minimum un résumé pour moi qui sera publié sur mon github, après si j'arrive à trouver le temps pour faire un vrai tuto dev.com ça serait cool en effet.
Dans les grandes lignes j'ai envie de te dire : tout.
C'est comme comparer une vieille micheline avec le TGV.
Le fond du problème c'est que Selenium pilote le navigateur via webdriver en mode black box. C'est à dire qu'il n'accède pas au coeur du navigateur, il le pilote depuis l'extérieur et il est complètement stateless. Donc lorsque tu écris tes tests avec selenium ou n'importe quel outil dérivé tu dois laisser le temps au navigateur de rendre le DOM en mettant des timeout de partout. C'est la raison principale qui fait que les tests via selenium sont horriblement lents à exécuter.
Cypress lui pilote le browser au travers de son API directement. Pour le moment ils ne supportent que webkit (ils vont écrire les adapters pour Gecko et Edge pour la fin de l'année), mais ils pilotent depuis l'intérieur. Donc ils ont accès à tout.
Lorsqu'un test est exécuté par cypress, il place toutes les instructions du test dans une queue, puis il exécute. A chaque instruction, cypress ré-exécute automatiquement la commande si elle a échouée jusqu'à sa réussite ou jusqu'à la fin du timeout.
Par exemple :
cy.get('#query-btn').should('contain', 'Button')
Cette commande cherche dans le DOM l'élément ayant pour id query-btn. Tant que l'élément n'est pas trouvé le framework retente le coup. Le .should('contain', 'Button') est une assertion disant que l'élément doit contenir le texte 'Button'.
La conséquence de ce fonctionnement c'est que si l'élément est trouvé il n'y pas besoin d'attendre la fin du timeout, cypress passe à la suite tout de suite.
Du coup un test e2e qui prenait 5 minutes avec Selenium prend 10 secondes avec cypress. Ça va aussi vite que le browser est capable d'afficher.
A chaque instruction exécutée par un test cypress prend un snapshot complet du DOM. Ça permet de faire du timetraviling dans le DOM après l'exécution du test et même d'ouvrir les outils de debug du navigateur pour regarder précisément quel était l'état du DOM au moment précis que l'on souhaite :-) Enfin du moment qu'on a une instruction évidemment.
L'autre conséquence de l'usage des API du browser directement c'est qu'ayant accès à tout on peut mocker dans tous les sens. En 2 coups de cuillères à pot il est possible de mocker directement XMLHttpRequest. Donc on peut réellement tester tous les cas qu'on veut niveau interface sans avoir besoin de programmer un back de test pour ça et l'appli n'y voit que du feu, aucun besoin de modifier une config de ton livrable puisque cypress agit comme un proxy.
Cypress est capable d'exécuter des tests d'intégration, de manipuler le système de fichier, et d'exécuter des CLI.
Donc on peut avoir une suite de test d'intégrations qui vont taper sur les backends à tester, enregistrer les résultats des requêtes, puis exécuter une suite de test e2e qui ferait appel aux mêmes endpoints, sauf qu'au lieu de taper sur les vrais backend on va charger les résultats des tests d'intégrations en stubant XMLHttpRequest.
On peut donc avoir les tests d'intégration + les tests e2e sans avoir besoin d'exécuter 2 fois le jeu de requêtes http, gros gain de temps !!
C'est également beaucoup plus facile de tester les cas d'erreurs des endpoints dans l'UI. Pour chaque call je peux simuler tous les cas d'erreurs http que je veux.
Bref c'est vraiment une avancée incroyable.
@el_slapper
Pas certain d'avoir tout compris à ton message, mais faire un clic attendre et recommencer oui pas de soucis à priori. Si t'as moyen de prendre quelques jours pour tester la bête tu y verras plus clair sur les possibilités.
Partager