Hello à toutes et tous, (ça c’est pour la formule de politesse pour pas se faire direct-basher par @Tonio-APEIF)
Plus sérieusement j’aimerais aborder la question des tests que notre superpote @regis a remis sur le haut de la table et j’aurais envie de croiser ça avec un super outil que @dolibarr_code42@egroult nous a présenté lors du devcamp de Lyon.
Mon approche sur ce fil d’échange du forum serait de ne pas s’adresser aux développeurs mais aux power-users car l’outil en question me semble tout à fait accessible pour des non développeurs : il s’agit de lancer l’enregistrement d’une séquence utilisateur (oui oui, une séquence « web ») dans dolibarr qui provoque un bug et ainsi faire progressivement une « couverture de fonctionnalités » de dolibarr.
Vous pourriez donc lancer une séquence « création d’un tiers » qui pourra ensuite être rejouée automatiquement par le robot de tests fonctionnels.
C’est un gros chantier qui sera probablement à remettre à jour à chaque nouvelle version de dolibarr mais qui apportera sans aucun doute une amélioration notable du projet.
Qu’en pensez vous ?
Si l’idée vous séduit il faudra trouver une solution pour regrouper les tests mais je ne suis pas inquiet à ce sujet (il s’agit d’un gros fichier texte à partager) … l’intelligence sera de bien étiqueter le test (version de dolibarr, quelles options actives au lancement du test etc.) …
Si ça vous tente je pense que dolizen peut fournir les instances de dolibarr pour créer les premiers tests avec des dolibarr préinstallés du genre « module association activé » ou « GPAO actif » etc.
Ensuite si ça prends vraiment il sera toujours temps de voir avec l’association pour avoir une plate-forme adaptée.
Merci encore pour toutes tes propositions !
J’ai rarement vu quelqu’un être autant force de proposition.
Pour les tests automatiques, ça me semble une bonne idée, même si avec les hash de session, je ne vois pas trop comment il va s’en sortir, mais prêt pour tester
Le souci avec les tests généré, c’est que le test porte les sélecteurs, et donc s’il y a changement dans la page HTML, il faut modifier les sélecteurs dans tous les tests.
Je préfère une architecture pageObject comme avec JDI light, ainsi si le code évolue, on modifie le sélecteur au niveau de l’objet et on n’a pas besoin de changer de code au niveau du test.
Avantage de cette solution aussi, c’est de faire une librairie avec les différentes pages, et de cette façon, permettre au dev de modules de l’utiliser pour interagir avec dolibarr sans avoir à tout réécrire.
@dev2a je suis 100% d’accord avec toi néanmoins l’approche que je propose permet à des non développeurs mais des utilisateurs avancés de s’impliquer et de réaliser des jeux d’essais sur la surface fonctionnelle / ui / interface ce qui apporterait BEAUCOUP à dolibarr à mon avis.
Il me semble important de proposer à une communauté des moyens de s’impliquer, celui ci me semble très concret et de mes expériences passées « perdre du temps » à réécrire des tests pour une version n+1 de l’application est un choix qui sera proposé aux contributeurs tout simplement.
Mais ça me semble plus facile pour un testeur avancé de s’appuyer sur des jeux d’essais et de les corriger lors de la sortie d’une nouvelle version tout comme « nous » développeurs nous nous appuyons sur des outils de ce genre au niveau de la couverture de code.
Et ça me semble être très cohérent avec l’idée d’avoir une version « LTS » de dolibarr, on pourrait imaginer avoir une couverture fonctionnelle des tests plus « larges » sur les LTS que sur les versions intermédiaires par exemple …
@ksar
voici ce que je propose, voici un dolibarr 18.0.5 « ouvert » pour vos tests, la base est issue de la base de tests / démo livrée dans le code source de dolibarr.
Mot de passe: (communiqué en privé je n’ai pas envie de voir arriver du spam et autres conneries)
Ensuite on installe chez nous https://playwright.dev/ et on fait une session de test par exemple création d’une facture et on regarde « si ça marche » / « comment ça marche ».
Au passage on explique sur le forum ce qu’on fait et / ou on documente au fil de l’eau sur le wiki ? j’ai ouvert la page suivante pour ça Communaute:tests - Dolibarr ERP CRM Wiki
Et niveau reproductabilité, si vous voulez dupliquer le dolibarr 18.0.5 de test vous trouverez le dump de la bdd ici : CAP-REL
Je ne suis pas développeur, et je suis volontaire pour participer.
je suis a 100% de l’avis de @erics « Il me semble important de proposer à une communauté des moyens de s’impliquer »
Je suis régulièrement confronté au jargon « métier », qui mérite un peu de vulgarisation.
1° Je suis aller voir l’outil « playwright » bon, j’ai pas compris grand chose, une ToDo pour non dev serait la bienvenue
2° une version LTS, c’est quoi ?
3° J’ai l’impression que la phase qui est en cours est réservée a des dev, car utiliser des dump, les cloner et qq autres éléments abordé dans ce fil (architecture pageObject, selecteurs, librairie etc etc ") n’est pas forcément a la porte des non développeurs, ou je me trompe sur le niveau attendu des « Key user » ou « power user »
