Les tests ne sont pas qu’un moyen de savoir si ton code marche ou pas, c’est une documentation vivante du code.
C’est un ingrédient clef pour augmenter ton bus factor.
C’est quoi le bus factor ? Ecoute l’épisode :
Participer dans l’Arène :
https://arene.artisandeveloppeur.fr/
Se former dans la maison des compagnons : https://maison.artisandeveloppeur.fr
C’est très intéressant et je commence à rejoindre ce point de vue. Toutefois j’aimerai avoir ton point de vue quand (dans l’entreprise dans laquelle je suis) on est stoppé par ce maudit argument que je hais de plus en plus : on n’a pas le temps. C’est du temps de dév’ supplémentaire et on n’a pas ça.
Ca me tue !!! Encore aujourd’hui je me rends de plus en plus compte de l’importance des tests unitaires même si ça « rallonge » du temps de développement. Au final, pour moi, c’est beaucoup de temps de gagné plus tard quand il faut maintenir le code ou le confier à un autre développeur. Enfin bref, tout ça pour dire que je rejoins l’idée !
Salut Ando,
Effectivement c’est un argument très répandu. En fait quand quelqu’un dit « je n’ai pas le temps d’écrire des tests unitaires » il dit en fait « je ne sais pas écrire des tests unitaires ».
Les tests unitaires et le TDD me font programmer 10x plus vite avec que sans.
Mais encore faut-il prendre le temps de se former pour apprendre à le faire.
Tiens… « Programmez 10x plus vite grâce aux tests unitaires » c’est un titre bien pute-à-click pour un article, non ? 😁
++
Je ne pense pas que le problème soit pris dans le bon sens. A chaque fois que j’ai chiffré et négocié du développement avec un client, ça a été en DTU o équivalent, c’est à dire Développement, Tests Unitaires mais parfois, voire souvent, les gens oublient la signification du TU. L’argument du temps ne tiens donc pas la route.
Je pense qu’effectivement, et je l’ai vécu avec des gars de mes équipes, le problème se pose plutôt sur le savoir faire. Quand j’entends mes gars me dire :
– je comprends pas à quoi ça sert
– Est-ce qu’il faut pas faire ensuite des TU des TU ?
– C’est trop long à écrire
Je me dis qu’il y a un vrai problème et que le moins coûteux serait de faire monter mes gars en compétences, de leur expliquer ce qu’est un bon TU, à quoi ça sert, comment on le met en place et quand. N’oublions pas que les TU peuvent aussi apparaître en phase de qualification, pour reproduire et corriger un bug, tout en s’assurant qu’il ne reviendra jamais.
Si ça n’a pas du temps gagné ça !!!
Effectivement ce sont des problèmes assez classiques.
Je remarque que même les plus sceptiques accrochent souvent quand ils font l’effort de s’y intéresser vraiment.
S’il y a le déclic, c’est gagné.
Mais comment provoquer ce déclic… J’y travaille dur ! 😁