Ouarzy's Blog

Ouarzy's Blog

Ce qui porte la vraie valeur, c’est tes tests

En codant au quotidien, vous avez des éclairs de lucidité qui vous prennent alors que vous êtes en train de coder. Et quand ça vous semble pertinent, vous pouvez même en faire un tweet.

 Sans titre.png

 

Et si ça vous fait toujours réfléchir 8 mois plus tard, pourquoi ne pas en faire un billet de blog?

 

Aujourd’hui je considère que la véritable valeur ajoutée d’un logiciel qui a vocation à évoluer et à être maintenu, ce n’est pas tant le code qui lui permet de fonctionner, que l’expression de la façon dont on voudrait qu’il fonctionne.

 

Les tests, à condition d’être bien écrits, sont des spécifications exécutables du code qu’on doit produire. Et d’ailleurs quand on l’envisage de cette façon, on se demande qui pourrait avoir la drôle d’idée d’écrire ses specs (donc ses tests) après avoir écrit son code…

 

De fait, la véritable intelligence n’est pas d’écrire ce qui est fait, mais bien d’exprimer ce qui est censé être fait par le code. Si on perd le code de production et qu’on a toujours sa suite de tests, il serait tout à fait envisageable de recréer le logiciel à moindre coût.

 

Par contre si vous n’avez plus de tests, il ne vous restera qu’un amas de code de production dont vous ne pourrez plus faire grand chose en termes d’évolutions et de maintenabilité. Et si vous voulez y remettre une suite de tests (comme sur un code legacy classique), ce sera fortement couteux.

 

 th8OQVYHTU.jpg

 

En caricaturant, votre code de production n’est qu’un détail de l’implémentation voulu par vos tests. Ecrire un logiciel non testé revient donc à se préoccuper du détail sans s’interroger sur le fond: que doit faire mon logiciel? Vous me direz que vous avez des fichiers Word qui expriment ces specs, je vous répondrais que ces specs déconnectées de votre code n’ont que très peu de valeurs.

 

Elles ne sont pas assez détaillées, ni automatisables, et la plupart du temps elles ne sont pas à jour du code. Et si elles le sont, c’est au prix d’un immense effort de travail mental et de relecture que mon esprit technique ne peut envisager. Si vous passez autant de temps à synchroniser manuellement vos specs et votre code, comment osez-vous dire à vos développeurs qu’écrire des tests est couteux? Penchez vous sérieusement sur des méthodes d’automatisation telles que le TDD ou le BDD.

 

Si nous concevions un paquebot, les tests seraient le matériel de mesure en temps réel. Ca nous donne les informations sur l’état actuel, concret des choses. Evidemment on peut naviguer sans aide, maladroitement, en essayant de ne pas couler. On peut aussi naviguer professionnellement en détectant les obstacles au plus tôt et en adaptant sa trajectoire. Tout le monde peut naviguer à vue, la valeur ajoutée d’un développeur c’est de montrer comment naviguer professionnellement.

 paquebot.jpg

 

Alors ne vous concentrez plus sur les détails, mais sur la vraie valeur. Apprenez à écrire des tests de qualité et utiles, car c’est cela qui rendra votre code pérenne et maintenable. Et n'oubliez pas que le premier à devoir maintenir votre code...C'est vous! Facilitez vous la vie, testez.

 

Pour finir un petit article complémentaire de l‘oncle Bob sur lequel je suis tombé peu de temps après mon tweet. Il s’en est probablement inspiré pour écrire son billet! (sans rancune Robert)

//blog.8thlight.com/uncle-bob/2013/09/23/Test-first.html

 

 



15/11/2013
0 Poster un commentaire
Ces blogs de Informatique & Internet pourraient vous intéresser