search

zestedesavoir / zds-site

Cœur du projet technique de Zeste de Savoir
https://zestedesavoir.com
Other
267 stars 162 forks source link

Ajouter des tests front (Selenium ou autre) #711

Closed SpaceFox closed 7 years ago

SpaceFox commented 10 years ago

Une bonne idée pour le futur serait d'avoir des tests front-office jouables par tout développeur, pour éviter les régressions du genre de celles que je viens de poster.

Un exemple d'outil est Selenium.

Je ne sais pas dans quelle mesure ça peut s'automatiser, à la fois côté dev et côté Github.

Alex-D commented 10 years ago

Ca serait cool, mais est-ce que du coup c'est dépendant de la structure HTML ?

SpaceFox commented 10 years ago

Oui. Comme tout test, il faut le maintenir à jour lorsqu'on fait des évolutions.

2014-06-04 21:29 GMT+02:00 Alexandre Demode notifications@github.com:

Ca serait cool, mais est-ce que du coup c'est dépendant de la structure HTML ?

— Reply to this email directly or view it on GitHub https://github.com/zestedesavoir/zds-site/issues/711#issuecomment-45139801 .

Alex-D commented 10 years ago

Du coup ça va être très lourd à maintenir... beaucoup plus que ceux du back. Une fois le code stabilisé ça me semble bien (d'où le père noël j'imagine), mais quand on change tout toutes les 3 secondes ça me semble tendu.

SpaceFox commented 10 years ago

C'est basé sur le HTML. Ca ne veut pas dire que le HTML doit être identique en permanence.

Par exemple si les éléments à vérifier ont un ID, il suffit que cet ID ne change pas.

Le 4 juin 2014 21:32, Alexandre Demode notifications@github.com a écrit :

Du coup ça va être très lourd à maintenir... beaucoup plus que ceux du back. Une fois le code stabilisé ça me semble bien (d'où le père noël j'imagine), mais quand on change tout toutes les 3 secondes ça me semble tendu.

— Reply to this email directly or view it on GitHub https://github.com/zestedesavoir/zds-site/issues/711#issuecomment-45140109 .

Alex-D commented 10 years ago

HS : ID = dédié quasi exclusivement au JS

Ok d'ac donc ça test la présence et la forme (au niveau du code) de ce qu'on veut.

J'ai jamais eu l'occasion de faire des tests front, d'où mes questions.

SpaceFox commented 9 years ago

Il me semble avoir vu passer des discussions à ce sujet sur les forums non ?

GerardPaligot commented 9 years ago

Sur les forums et IRC, une idée qui se fait de plus en plus persistante (je ne dirais pas par qui sous risque de voir cette issue fermée ^^).

SpaceFox commented 9 years ago

Merci de ne pas troller dans les issues…

AmarOk1412 commented 7 years ago

Coucou,

je remonte l'issue parce que je la trouve utile. J'ai un peu cherché pour voir ce qu'on peut faire. Selenium peut-être mis en place avec Travis CI en passant par Sauce Labs :

  1. https://saucelabs.com/blog/run-your-selenium-tests-completely-in-the-cloud-using-travis-ci-and-sauce-labs
  2. https://docs.travis-ci.com/user/gui-and-headless-browsers/

Note : Sauce labs est gratuit pour les projets open-source : https://saucelabs.com/open-source

Niveau maintien, au final c'est pas énorme pour les parties qui ne bougent pas tous les jours. Par exemple, le fonctionnement des forums, des galleries, du profil ou encore des tutoriels/articles peuvent être testés. Niveau prise en main, la plupart du temps ça se fait facilement. Par exemple sur Firefox il y a Selenium IDE, il suffit juste de se rendre sur la page, lancer l'IDE, faire record pour que le test se fasse de manière automatique. Il reste plus qu'à ajouter quelques commandes pour tester la présence de quelques valeurs dans la page.

En gros, pour faire ça, il faudrait :

Voilà,

AmarOk1412 commented 7 years ago

Ouai du coup juste pour dire que je vais travailler sur ça

AmarOk1412 commented 7 years ago

Hop, petite mise à jour pour changer un peu avec mes premières tentatives :

Ce qu'on souhaite (AMHA)

Je pense qu'ici personne n'a envie qu'entre chaque commit on se tape 30 minutes voir plus (beaucoup plus) de tests. Clairement c'est pas pratique. Le problème est que Selenium est lent, et que même en parrallélisant les suites, le temps sera pas négligeable du tout. En plus, alourdir le processus de dev côté front en obligeant l'apprentissage d'un nouvel outil (i.e. Selenium), c'est pas jouable non plus et ça risque d'en rebuter certains. Il faut donc un truc jouable niveau temps de build, qui puisse faciliter la QA côté front et super facile à prendre en main côté dev avant même de penser à l'automatisation. Pour ça, Selenium possède un IDE qui est juste super facile à prendre en main (on ouvre la page, on fais Ctrl+N, on appuie sur enregistrer, et ça enregistre tous nos clics, on a juste à ajouter quelques commandes un peu plus manuellement (controle d'un id par exemple). L'IDE s'installe via une extension navigateur en quelques secondes et on peut importer/exporter des suites de tests pour les jouer/modifier. Le "probleme" c'est que meme si l'export depuis l'IDE est dispo en JAVA/Ruby/Python (sauf les suites de tests)/HTML, l'import vers l'IDE ne marche que via HTML, hors pour la modification d'une suite, l'import d'une suite depuis l'IDE c'est pratique.

Ce que je propose

Pour les devs front

Du coup, ce que je pense jouable c'est qu'on demande aux dev front ce qu'on fait en back, nouvelle fonctionnalité = nouveau tests. Pour rendre le processus simple, un dev aura juste à utiliser l'IDE Selenium. Soit il créé une nouvelle suite de tests, soit il modifie une existante, puis il exporte les tests et la suite une fois son test créé. Pour lui, ça revient à controler ce qu'il a développé et ça ne doit prendre que quelques minutes (bon peut etre un poil plus la première fois)

Pour la QA

Pour la QA, pareil, pour éviter un l'apprentissage d'un nouvel outil ça doit-être simple. Alors certes, il y aura un test Selenium à lire (ou une suite), mais un test est très facile à lire (cf plus bas). Après pour tester ils auront 2 solutions :

  1. Importer la suite de tests dans l'IDE installé sur leurs machines, lancer l'instance, appuyer sur RUN et attendre quelques minutes que la suite s'éxécute. Ou seulement jouer le test.
  2. Lancer un make test-front depuis le dossier du site qui executera toutes les suites. Ou alors aller dans le dossier tests-front et faire un make suite_xxx.

Pour l'automatisation

L'avantage de Selenium est qu'il est très utilisé et que y a des travaux pour son automatisation, cf Sauce Labs de mon message plus haut. Par contre, niveau durée ça peut prendre un temps fou, même avec des jobs parrallèles. Du coup ça peut être pas mal de runner les suites avant une release, de temps en temps ou comme pour Mozilla, avant le merge (ça prend quelques heures à chaque fois avant que le patch soit testé sur toutes les plateformes alors bon), mais pas avec tous les commits.

Ce que ça donne

Un petit aperçu est ici : https://github.com/AmarOk1412/zds-site/tree/tests_front

En gros côté Makefile ça change 

test-front:
     make -C tests-front

avec test qui fait test-back + test-front, et le reste est dans https://github.com/AmarOk1412/zds-site/tree/tests_front/tests-front ou on peut voir quelques tests dans connection/tutorial, une suite dans zds_suite.html

Limite faudrait rajouter un script pour lancer la bonne suite selon les changements effectués sur les commits qu'on veut tester mais bref, dans l'idée ça donne ça.

Voilà,

motet-a commented 7 years ago

Je me permet de déterrer vu que la PR a été fermée récemment.

Du coup, ça en est où ? Ça pourrai faire gagner pas mal de temps. Si ça peut vous être utile, je m’étais amusé récemment à lancer Selenium directement chez Travis, sans passer par Saucelab. Bon, évidemment c’est lent et un peu hackish (faut compter de quelques dixièmes de secondes à quelques secondes par tests).

AmarOk1412 commented 7 years ago

@motet-a cf #4526 pour le coup :)

Et ça utilise Selenium sans passer par Saucelab pour Travis (et sans Docker).