mageekblog - Mot-clé - tests manuels - CommentairesLe blog personnel de Frédéric Hardy. Au menu, PHP, agilité, FreeBSD, cuisine et photographies.2021-12-02T08:20:54+01:00Frédéric Hardyurn:md5:26874ca5b8cd4cac8d08b0e68e64f63aDotclearÀ propos de la politique de développement de atoum - Renaudurn:md5:f5a9618d590d5449258cfb7bac8465a42013-04-27T08:31:18+02:002013-04-27T21:48:47+02:00Renaud<p>@<a href="http://blog.mageekbox.net/?post/2013/04/26/A-propos-de-la-politique-de-d%C3%A9veloppement-de-atoum#c5077" rel="nofollow">Yoann</a> : Mageekguy, sur irc, me dit la même chose que toi, mais vous ne comprenez pas quel mot m'a fait bondir. C'est le mot "transparent".<br />
On ne peut pas dire que c'est transparent. C'est comme si j'étais livreur, que je devais faire le trajet Marseille-Paris le plus vite possible (c'est une demande de mon patron) et que je fais un détour par Lyon et Strasbourd. Même si à terme, ça va me faire gagner du temps parce que je profite de ce voyage pour livrer d'autres colis et donc, que je n'aurai pas à faire ces voyages la semaine prochaine, ce n'est pas transparent. Sans ces détours, j'aurais mis 10h de trajet et là, j'en ai mis 15. MAIS ça m'a fait gagner du temps sur mes futurs boulots puisque je n'aurai pas à faire 2 autres trajets de 6 et 8h une autre fois.<br />
Ok, c'est un exemple en carton, mais ce que je veux dire c'est que "intégrer le cout des tests" et dire que c'es transparent, c'est comme dire "intégrer le temps des détours" et dire que c'est transparent. Écrire 12 lignes de tests, c'est du temps que tu ne passes pas à écrire 12 lignes de code. Indépendamment du fait que ça structure mieux ton code, que tu "t'assures" de ne pas faire d'erreur et du temps gagné plus tard lorsque tu voudras rajouter une feature ou refactorer ton code. À **très court terme**, c'est "du temps perdu". Et comme je le dis dans le dernier paragraphe de mon précédent commentaire, c'est justement cette sensation de temps perdu SI ON A UNE VISION À COURT TERME UNIQUEMENT qui rebute pas mal de développeur à se lancer dans l'écriture de tests.<br />
Qu'on soit bien clair, je ne dis absolument pas que c'est du temps perdu et qu'il ne faut pas écrire de tests, bien au contraire. Je tique sur le mot "transparent".</p>
<p>De toute façon, soit c'est comme je dis et le temps pris à faire des tests rallonge le développement d'une feature et n'est donc pas transparent, soit c'est comme vous dites, toi et Mageekguy, et le développement avec les tests vous en fait gagner... et n'est donc pas transparent non plus <img src="/themes/default/smilies/smile.png" alt=":)" class="smiley" /><br />
Mon expérience personnelle me montre que je prends plus de temps à développer à l'instant t qu'en j'écris des tests mais que j'en gagne bien d'avantage au fur et à mesure de la vie du projet/de la feature. Je ne pense pas que ce soit vraiment quantifiable mais certaines fois, j'ai vraiment l'impression de gagner plusieurs heures voire plusieurs jours grâce aux tests.</p>À propos de la politique de développement de atoum - Yoannurn:md5:2daf1294802576e6eb7e8df13cb5d29b2013-04-26T20:19:28+02:002013-04-26T22:53:00+02:00Yoann<p>@<a href="http://blog.mageekbox.net/?post/2013/04/26/A-propos-de-la-politique-de-d%C3%A9veloppement-de-atoum#c5075" rel="nofollow">Renaud</a> : Je suis pas tout à fait d'accord avec toi, tu vois l'écriture des tests unitaires comme un surplus de code et donc de temps, alors que ce temps perdu peut permettre d'économiser du temps de test même sur du très court terme durant le développement de la fonctionnalité. Cela peut aussi permettre de se forcer à avoir une réflexion sur la manière de découpler son code en amont car cela facilitera la mise en place des tests unitaires et donc évitera ultérieurement (au moins partiellement) d'avoir à faire du refactoring (du temps que l'on nous accorde pas forcément). Attention je ne dis pas que cela est forcément vrai dans tous les cas, juste qu'on ne peut pas forcement dire qu'écrire des tests unitaires soit une perte de temps sur du court terme. Après sur la raison de pourquoi beaucoup de développeurs boudent les tests unitaires, je pense simplement que beaucoup n'en voient tout simplement pas l'intérêt et ne cherchent pas à le voir. Surtout que cela demande un temps d'adaptation et de casser toutes ses habitudes de développement.</p>À propos de la politique de développement de atoum - Renaudurn:md5:44ba2c70bc509b667aa2c3eafe4c94e72013-04-26T16:47:50+02:002013-04-26T16:16:38+02:00Renaud<p>"Et si d’aventure le développeur fait du développement piloté par les tests, le coût des tests est alors intégré au coût du développement et devient donc totalement transparent"<br />
Je ne suis point d'accord avec toi sur cette phrase en particulier alors que je suis d'accord avec le reste.<br />
Mais non, le coût du test n'est pas transparent car écrire ses tests prends un certain pourcentage de temps en plus que si on ne l'écrit pas. Ce petit pourcentage est totalement récupéré sur la durée de vie du projet lors de la correction de bug, l'ajout de feature ou le refactoring, mais il n'est pas transparent lors du dev.<br />
Et c'est précisément la raison pour laquelle autant de dev refuse d'en faire car ils estiment que c'est une perte de temps. Ils ont raison à très court terme, car si un dev avec tests prend 1 journée, un dev sans tests en prenant probablement 25 à 50% de moins (données venant du pifomètre de compétition que je me suis offert à noël dernier). Mais ils ont totalement tord sur le long terme.</p>