Le TDD à l’ancienne
Je fais de temps en temps des cours / TD ou TP à l’Université : ça oblige à formaliser les connaissances, à prendre du recul sur les méthodes, et c’est sympa de rester au contact de jeunes qui n’ont pas leur langue dans la poche pour critiquer un bout de code, une approche, etc.
Jusque l’an passé, je leur parlais de Test Driven Development à partir d’un algorithme supposé compter les mots dans une phrase. On partait du cas le plus simple possible :
Puis je leur demandais d’ajouter de plus en plus de tests, et de faire en sorte que l’algorithme suive, sans toutefois prendre trop d’avance sur ce qui était réellement nécessaire.
Après un peu de temps, on trouvait des cas un peu plus compliqués, et en général, les deux heures habituelles étaient passées.
De temps en temps, je fais ce TP en mode attaque / défense, en séparant les groupes en deux équipes de deux ou trois personnes : la première s’occupe uniquement de créer un test en plus pour faire planter l’algorithme, et la seconde s’occupe de faire la correction minimale pour que les tests passent.
Lors de la première itération, beaucoup d’étudiants ont du mal à comprendre pourquoi la fonction SUT prend la forme simpliste suivante :
Je dois bien avouer que cette approche “do the simplest thing that can possibly work” m’a souvent causé des noeuds aux méninges. Dans ma conférence “Architecture et Agilité : réconcilier les frères ennemis”, j’expose d’ailleurs mon point de vue dessus, à savoir que je trouve YAGNI supérieur en utilisabilité et en simplicité (point de vue binaire, au lieu de qualitatif). Or, cette première version de mon TP sur le TDD ne permettait pas vraiment d’aborder ce sujet. Il se trouve que la deuxième version, plus ludique, le fait apparaître, et ce sans même que je l’ai prévu à l’origine. Mais j’anticipe sur les résultats.
Un peu plus ludique grâce à la Kinect
Déjà, je souhaitais faire quelque chose de tout simplement plus fun. Vous savez comment sont les étudiants : dès que vous faites un truc un peu trop académique, certains sont fainéants, et ne veulent pas faire l’effort intellectuel pour s’approprier le problème. A l’inverse, si vous faites quelque chose de ludique, pas un seul à regarder en douce son portable ou son compte Facebook sur l’ordinateur de TP quand vous n’êtes pas derrière…
Du coup, quand on leur fait voir ceci, tout le monde cherche la solution du TP :
L’algorithme ciblé est tout simplement une recherche de lettres correspondant au positionnement du squelette. Pour faire simple, voici le A :
Ensuite, le C :
Ensuite, le M (cas un peu plus compliqué parce que le triangle Centre Epaule – Main Droite – Main Gauche est le même que pour une lettre A) :
Et en dernier le Y :
Le principe du TP est lui aussi simple : de la même manière que, dans une équipe de développement, il y a beaucoup moins de testeurs que de développeurs, dans le groupe de TP, il y a une vingtaine d’étudiants, mais une seule Kinect. Il est donc bien entendu hors de question que chacun transbahute son code par clé USB sur mon ordinateur pour tester à chaque fois qu’il réalise un changement dans son algorithme.
En ce sens, le capteur physique Kinect simule le goulet d’étranglement de la Quality Assurance dans une équipe de développement.
Approche TDD
Pour faciliter l’approche, je vais jusqu’à donner aux étudiants les deux premiers cas de test :
Ensuite, le TP permet de montrer que la signature de la fonction doit évoluer au fur et à mesure des tests, et donc qu’il y a bien émergence du code, y compris dans sa signature. En effet, pour traiter le M, on est obligés de rajouter deux points correspondant aux coudes. On les rajoute bien sûr à la fin pour la compatibilité ascendante, et on vérifie que les tests unitaires fonctionnent toujours bien.
Pour simplifier le TP pour ceux qui ne font pas trop de POO, je fais réaliser la signature avec des entiers plutôt que des instances de Point.
Premiers algorithmes, et coup de chaud pour le prof
Une fois les premières itérations réalisées sur ces quatre premières lettres cibles, je commence en général à avoir quelques premiers algorithmes qui font passer les tests unitaires de reconnaissance lettre par lettre au vert.
Et là, grosse frayeur : les premiers algos fonctionnels sont bien plus simples que celui que je leur ai préparé comme correction ! Le honte se profile 
. Voici par exemple le code d’un étudiant pour la détection de la lettre Y :
Simple, efficace : la lettre Y est la seule pour laquelle les deux mains sont au dessus des épaules (à noter que l’axe y augmente vers le bas pour le repère Kinect). Rien à redire là-dessus : je leur avais bien dit “le plus simple algorithme qui fasse passer les tests”.
Et moi, derrière, je n’ai pas l’air fin avec le mien :
Surtout qu’il faut en plus la fonction APeuPresEgal ci-dessous :
Et que, cerise sur le gâteau cageot, elle-même a besoin de EstEntre :
Pour un codeur “professionnel de l’agile”, ça s’annonçait mal…
Mais 25 ans d’expérience feront toujours la différence !
Je commençais à sentir le souffle de la guillotine sur ma nuque quand je me suis rendu compte que la faible différence entre A et M allait me sauver. Dans le même ordre d’idée, les étudiants avaient codé la reconnaissance de la forme A comme la seule avec les mains en bas, et à condition que les coudes ne soient pas au même niveau en x que les mains (sinon, il s’agit d’un M). Du coup, que se passe-t-il quand les mains passent de Y à M ? En descendant, il est extrêmement difficile d’avoir déjà les avant-bras verticaux au moment où les mains passent en dessous des épaules.
Résultat : aucun n’a réussi, malgré les 4 tests unitaires en vert, à écrire YMCA !
Le logiciel affichait toujours ceci :
Seul Olivier (félicitations à lui) a réussi à créer une itération supplémentaire avec le bon test et la modification de l’algorithme pour pouvoir passer le test et arriver ainsi à ceci :
Conclusion
Finalement, j’ai appris moi-même peut-être autant que mes étudiants sur ce TP. Ca faisait longtemps que cette idée de “simplest thing that could possibly work” m’embêtait, mais je ne trouvais pas de contre-exemple. Et bien en voici un… En faisant le plus simple possible pour chacune des lettres, on s’est d’une certaine manière forcés à réaliser un algorithme strict. Sans cette restriction, je suis parti sur un algo un peu plus souple, qui a dès le début été propre pour gérer les transitions d’une lettre à une autre.
Evidemment, en théorie, il aurait fallu commencer par faire les tests unitaires de transition d’une lettre à l’autre, mais :
- Ils sont beaucoup plus nombreux
- Ils sont complexes à réaliser, car fonctionnant avec n échantillons poussés à la suite
- Le rendement est moins bon au final, car on serait arrivés à l’algorithme souple en seconde version
