Tests : de quelle couleur est la boite ?

L'URL courte de cet article est : http://inagua.ch/WFTWb

Récemment, j’ai de nouveau entendu cette phrase que je n’avais plus entendue depuis quelque temps… Chaque fois cette même réaction épidermique qui me fait dresser les poils !…

” C’est plus pro que ce ne soit pas le développeur d’une fonctionnalité qui écrive lui même son test. “

Je suis rentré chez moi en y réfléchissant…

Boite blanche ou boite noire ?

Boite blanche ou boite noire ?

Soit on parle de test fonctionnel, soit on parle de test unitaire.

Le test fonctionnel est une boite noire : on doit tester la fonctionnalité, sans savoir comment elle est réalisée en interne. De plus, n’oublions pas qu’un test peut jouer (“doit” en XP ;) ) un autre rôle qu’identifier les bugs : il spécifie le comportement. Or, quelle est la meilleure personne pour connaitre le fonctionnel si ce n’est le client ?!… Donc, il semble logique que le développeur n’écrive pas lui même le contenu du test fonctionnel… Il peut par contre aider le “client” à l’écrire. Dans tous les cas, c’est le client qui reste responsable du test fonctionnel et de son contenu.

Revenons au test unitaire… Pour le coup, nous parlons de tester une classe… Qui est la personne la mieux placée tant pour connaitre le fonctionnement d’une classe que pour débusquer les bugs inhérents à sa réalisation ?… Qui est le mieux placé pour savoir qu’il faut faire attention à la valeur null du paramètre de telle méthode ? Je dirais… Le développeur ! Nous sommes ici dans une approche “boite blanche”, où celui qui écrit le test connait tous les recoins de l’entité testée.

Du coup, je n’ai pu m’empêcher de demander à mon collègue le lendemain : “c’est ton avis ou c’est Chef qui l’a demandé ?!…”
A ce moment, j’étais “responsable d’écrire les tests unitaires pour le nouveau module en train d’être écrit sur le projet”…
Après discussion, il s’avère en fait que cette remarque n’était pas complètement infondée. Dans ma tête j’écrivais des tests unitaires, car je travaillais sous JUnit en manipulant des classes… Cependant, en y réfléchissant, j’ai perçu un “bad smell” : j’étais incapable de nommer mes méthodes de test d’après le nom de la méthode que je testais !… J’étais donc en train d’écrire un test fonctionnel ! Un “test unitaire” selon le vocabulaire utilisé sur l’openspace, mais qui regarde le résultat de plusieurs classes, sans se soucier de l’implémentation.

Se pose ensuite la question de savoir quand est-ce que l’on écrit le test : avant ou après le code testé… Je vous mentirais en vous disant que je n’ai pas une réponse sur le sujet… Mais cela fera l’objet d’un autre post…

L'URL courte de cet article est : http://inagua.ch/WFTWb

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

*


*

Vous pouvez utiliser ces balises et attributs HTML : <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>