Salut beaux enfants du monde numérique,
la discussion s'est engagée il y a un peu plus d'une semaine sur un sujet hautement important, j'ai nommé : les tests unitaires
En fait, j'ai des collègues qui doivent développer des bouts d'un gros soft et leur client
leur a demandé un taux de couverture de test du code de 80%.
Technique : les tests unitaires
vous me direz que jusque là, il n'y a rien de choquant mais en y regardant de plus près, je me suis demandé jusqu'où devaient aller les dits-tests.
En effet, la construction d'un soft dont seules les interfaces externes sont spécifiées ne devrait-il pas s'assurer du bon fonctionnement de ses dernières et opérer un fonctionnement boîte noire
pour le reste ?
Personnellement, j'aurais tendance à dire que oui puisque par la suite, il y a des logiciels de vérification de couverture de code.
Cependant, pour un de mes collègues, tout code écrit doit avoir son test unitaire.
Il semble donc y avoir deux approches :
- le test unitaire comme vérification du bon fonctionnement d'un programme ou d'un ensemble de fonctions de bibliothèques et
- le test unitaire en tant qu'outil de développement[1].
Bon, je suis assez open comme garçon[2] mais un test unitaire pour toute ligne écrite
n'est-il pas une sorte d'intégrisme ?
Jusqu'où doit-on aller dans le test unitaire ? Faut-il écrire un TU pour le moindre accesseur ou pour tout code aussi simple ? Ne suffit-il pas d'écrire un test unitaire pour les méthodes exposées à tout développeur ?
La réponse du collègue à ce dernier sujet est qu'il faut un test pour tout code point barre et qu'en plus, cela aide à trouver les problèmes[3]. Certes... Les sorties écran aussi[4] !
Alors quoi ? Doit-on réellement écrire 200 lignes de code de test pour trente lignes de code effectif ? Boîte noire ou boîte blanche ?
si toi, codeur, tu as la réponse, je suis preneur car sur le grand Ternet, nul ne donne de réponse très satisfaisante.
