@dev2a ne te prend pas la tête, je suis un ange ! 
Croire que l’on peu tester tous les cas possible d’un programme est une erreur de débutant. Mes modules sont bourrés de bug, sans parler que mes utilisateurs sont assez incroyable pour les détourner de leur usage initiale… Le mieux est pour moi de réaliser des modules simples, facile à comprendre, utiliser (comme peut d’utilisateur lisent la doc de toute manière) et maintenir (il me faut moins de 5 mins pour corriger une erreur, packager une nouvelle version du module et la mettre en ligne sur le dolistore (meme si la dernière étape reste manuelle…)
Développer des modules est à mes yeux assez simple pour quelqu’un qui a des bases en php, mysql, on est loin d’une architecture à la wordpress ou prestashop et je ne parle pas de odoo. Ensuite le métier de développeur ne se limite pas à « pisser » du code, je passe la plus grande partie de mon temps à comprendre les besoins de mes clients et transcrire cela sous la forme de process ergonomique que je traduits ensuite en code, c’est sans doute cet aspect qui fait la différence.
Croire que l’on peu devenir riche en développant des modules dolibarr, c’est en parti vrai mais si c’était le but au départ j’aurai sans doute choisi des modules pour wordpress, presta voir meme google chrome. Avec l’ensemble de mes modules j’arrive à peine à 20K de revenus annuel (bien que que 5 sont dans le top 10 des ventes), c’est le dev et les formations à coté qui me permette de bien vivre, j’ai une certaine forme de rente…
Est-ce pour autant que je me considère comme une bonne développeuse?
Un ami m’a dit un jour « on ne devient pas restaurateur parce que l’on sait couper des tomates ».
Je pense qu’il faudrait des tests « end to end » pour Dolibarr.
Cela aurait deux avantages :
- pouvoir lancer une batterie de tests automatisée qui permettrait de déterminer si l’ajout d’un module provoque des erreurs
- lancer également ces tests automatisés pour les PR sur github ce qui permettrait de déterminer si une PR introduit un bug dans le fonctionnement de Dolibarr.
Croire que la présence de tests automatique garantira la qualité d’un développement… ca tu peux le raconter à des clients, pas des développeurs…
???
j’ai franchement du mal à comprendre tes réponses
L’ajout de tests automatisés ne peut être que bénéfique à tous les développeurs.
Et c’est un jeu d’enfant de construire des tests avec par exemple codeception
Je parle d’expérience, je préfère prendre du temps sur la qualité d’écriture de mon code pour le rendre facilement maintenable que de mettre en place des tests automatisées qui au final ne prendront jamais en compte tous les cas possible.
Doubler mon temps d’écriture de code en incluant des tests fera baisser ma rentabilité sans m’assurer une augmentation significative de la qualité.
Ma vision des choses est pourtant en train d’évoluer, sans doute que dans peut de temps je demanderai à une AI de m’écrire du code pour tester mes classes mais cela demandera de mettre en place une infrastructure conséquente d’intégration. Bref pour moi cela n’en vaut pas encore la peine, sans parler que j’ai beaucoup de clients utilisant mes modules qui me remonte des anomalies quand ils en rencontrent…
Et je ne parle pas des variantes possibles entre les versions de dolibarr, php, les bases de données, … qu’il faut prendre en compte pour etre exaustif…
Je préfère être rapide sur la résolution de bug que d’avoir des tests automatisées qui ne garantiront mon code qu’autant qu’un parapluie quand il fait beau
Les tests feraient partie du code de Dolibarr, un développeur de module fait ce qu’il veut. Il écrit ou pas des tests pour son module.
La suite de test comme déjà expliqué, permettrait de tester si l’ajout d’un module externe casse des fonctionnalités vitales de Dolibarr.
Si on a un test pour l’ajout d’une note privée sur une facture, on détecte alors si le module qu’on ajoute casse cette fonctionnalité ou pas.
Je conçois que si on n’a jamais utilisé d’outil de test « end to end » on ait du mal à concevoir ce que cela pourrait apporter à Dolibarr.
c’est surtout qu’il il a dejà des tests présents dans dolibarr …
Merci bien avec grand plaisir.
Je dois prendre plus connaissance de vous de votre outil… je suis certaine que je peux contribuer un peu à son évolution ou sa stabilisation.
Avec le temps que vous avez perdu à vous balancer des fions, vous aurez pu en tester des lignes de code .
Ok —> je sors 
6 « J'aime »
Excellent 
Je répondais de la main gauche en faisant les tests de la main droite.
Quand je développe sur dolibarr, il est compliqué de mettre en place des tests complets (seulement test partiel des éléments principaux) et lorsque je dois changer un comportement, j’y vais à reculons et ça me prend plus de temps.
Quand je développe des applications avec des frameworks (Laravel, Symfony), c’est test avec couverture élevée couplé avec Infection pour me dire les tests ou il maque des vérifications. Dans le cas de changement, je ne réfléchis pas, j’implémente, je vois ou ça casse en lançant mes tests et je corrige ce qui ne fonctionne plus.
De plus, pour les implémentations un peu compliquées, je commence par écrire les tests, et ainsi, pas besoin de tester manuellement l’implémentation, je lance ces tests pour voir si la fonctionnalité est bien implémenté.
Donc oui, ça prend du temps, mais le gain derrière est largement rentabilisé
3 « J'aime »
Petite aparté à ce sujet j’avais identifié aimeos (Aimeos) · GitHub mais comme ça n’est pas du tout mon coeur d’expertise (ecommerce) c’etait dans ma todolist … j’ajoute sylius au passage merci 
Bonjour Monde,
je suis assez d’accord avec @defrance
les tests automatisés ça va bien pour la qualité du code, mais pour l’utilisation finale et gérer tous les cas de figures rien de tel que l’humain !
Un robot si tu lui dis « fait ça » il va faire ça !
Un humain tu lui dis « fait ça » il va réfléchir… discuter avec sa ou son collègue… boire un café… rigoler, draguer… et puis il va regarder sa montre et se dire, mince ! c’est l’heure de bosser… et il aura oublier « fait ça » ! Du coup il va le faire autrement et bug !
Avec ça il faut prendre en compte les différences de serveurs, de modules additionnels, de méthodes et pour peu que ce soit un jour de pleine lune !
Tout ça c’est la faute à Macron de toute façon !
1 « J'aime »
Si des âmes généreuses veulent apporter leur contribution afin de m’aider à rédiger une documentation, ou tout du moins m’orienter sur un schéma de chapitres, un début de fondation, je suis preneur. Je vous serais redevable à vie !
Je ne vous promet pas les grands soirs, mais une bonne bouffe en compensation !
les inscriptions sont ouvertes :
Kiss kiss bang bang
1 « J'aime »
j’ai tout dans la tête mais je n’arrive pas à le mettre en forme !
Hello Régis,
J’ai aussi eu ce « syndrome de la page blanche » coté documentation,
à l’époque j’ai travaillé avec Romain, on a sortie des versions pdf mais c’était bien la galère à maintenir et je suis passé à un wiki pour chacun de mes modules (avec un bonus, pouvoir accéder à la bonne page de documentation depuis l’application).
J’utilise pour cela médiawiki, j’ai crée un sous-domaine « wiki » associé. et petit bonus j’ai ajouté des bannières de pub . Si tu as la flemme de te monter un site pour cela, rien ne t’empeche de te servir du wiki de dolibarr (meme si il y a un risque que quelqu’un vienne y écrire des trucs bon ou moins bon)
coté structure, rien ne t’empêche de t’inspirer de la présentation de mes modules
1 « J'aime »
Hello Régis,
Je peux aider à documenter pour les utilisateurs si besoin.
Personnellement j’ai tourné « en rond » pour 2-3 trucs avant de comprendre la logique.
Je pense que @erics pourra attester que s’il y a un bug, un détail je vais mettre le doigt dessus 
Au plaisir !
Cdlt,
Mathieu
1 « J'aime »
Et j’ajoute que, pour ma part, je suis client depuis des années de Milestone/Jalon, que j’essaye de faire remonter un bug depuis tout ce temps sur les factures modèles programmées où les jalons ne sont pas correctement pris en compte, ni à l’affichage, ni à l’édition.
Et que j’ai l’impression de parler dans le vide depuis tout ce temps…
Je suis prêt à faire une visio avec partage d’écran pour montrer le bug
1 « J'aime »
