@hop oui et demain ce sera autre chose… tout va trop vite !
je vais finir par vendre des crêpes dans un bus anglais ! 
c’est public maintenant.
Je pense que c’est ce qu’on fait tous avec chacun un niveau de connaissance et de compréhension du fonctionnement de dolibarr différent qui fait que parfois, il y a des loupés.
@dev2a oui c’est moi qui ai mis cette méthode de calcul sur Dolistore ! sauf que les chiffres ils se base sur le début de la vente ! j’ai commencé à vendre Multicompany sur Dolistore en 2011 !!! maintenant si tu divises !
et en plus le prix en 2011 n’était pas le même qu’aujourd’hui !! tu veux le détail de l’évolution ?!
Franchement je me brade !
@dev2a j’ai développé du dolibarr quand tu jouais aux billes avec tes amis… permet moi de te dire que j’ai beaucoup donné à ce projet et que si je suis aussi critique c’est que le temps je l’ai vu passer et que j’ai une vision assez clair de ce qu’il faut faire ! Maintenant je ne veux pas remettre en cause tes compétences… elles sont surement respectables, mais respectes les miennes s’il te plait…
À quel moment j’ai remis en doutes tes compétences ?
Quand je parle du niveau de connaissance de dolibarr, c’est pour dire qu’il faut avoir un peu plus de tolérance envers les autres, car tout le monde n’a pas le même niveau.
Je n’aurais rien d’autre à ajouter sur ce sujet.
@dev2a ok je comprend… bien sur on ne peux pas tout connaitre… j’en convient.
Il faudrait vraiment une « police » qui vérifie la validité d’un module ! @Sara1 tu aurais la capacité d’être en charge de cette responsabilité ? une personne qui teste les modules dans tous les « cas de figures » avec un « cahier des charges », genre un test à la github mais humain qui permettrait de déterminer si un module est pleinement compatible ?
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 
