4. Faire des tests le moteur du développement

4. Faire des tests le moteur du développement

4.1 Ce qui définit le TDD

Le Test Driven Development, ou développement piloté par les tests, est attribué à Kent Beck dans la séance, avec la contribution d’autres personnes. Il ne consiste pas simplement à posséder des tests automatisés. La vérification du prochain comportement est écrite avant le code de production qui devra le réaliser.

Le test devient un outil de conception : il exige une réponse précise à la question « que doit faire le prochain petit morceau? ». Il guide l’implémentation au lieu d’être une activité repoussée après la résolution du problème.

4.2 Rouge, vert, refactoring

La taille des pas compte. On répète le cycle pour des comportements suffisamment petits pour comprendre rapidement un échec et son correctif. Le stade vert n’exige pas de résoudre d’avance tous les besoins possibles. La phase suivante permet d’améliorer une solution devenue correcte pour les scénarios actuellement définis.

Le refactoring n’a pas à produire artificiellement une modification. Au premier cycle, le code peut être trop minime pour avoir quelque chose d’utile à réorganiser. Il faut examiner la structure et intervenir quand cela apporte une amélioration réelle.

4.3 Pourquoi déplacer les tests avant aide aussi la discipline de travail

Après avoir résolu un problème, on obtient la satisfaction de la réussite et l’envie de passer au suivant. Les tests écrits après peuvent paraître moins motivants. La pression d’échéancier ou une réaffectation peut aussi les sacrifier : le travail semble fini et l’on décide de l’utiliser sans preuve suffisante.

Les écrire avant place la vérification dans la résolution elle-même. Le retour au vert marque une réussite qui inclut ce contrôle. Ce mécanisme réduit la tentation de supprimer la protection au dernier moment; le TDD est donc aussi une discipline pour rendre le travail de qualité moins dépendant de la motivation restante.

4.4 L’analyse se fait pendant l’écriture du test

Pour formuler un scénario, il faut comprendre les entrées, les sorties, les cas limites et la manière d’utiliser la composante. Ce travail prépare le code. Le développeur a déjà réfléchi aux erreurs possibles et au résultat qui permettra de juger sa solution.

Le conférencier rappelle que le développement substantiel repose beaucoup sur la lecture du code existant et sur la réflexion. La vitesse de frappe ne mesure pas la qualité du travail. Concevoir le test est une partie de cette analyse; ce temps n’est pas simplement une activité supplémentaire qui arriverait après une conception déjà parfaite.

4.5 Documentation exécutable et débogage

Les tests donnent des exemples d’utilisation et rendent visibles des attentes importantes, notamment pour une entrée nulle ou vide. Ils complètent des noms explicites et des commentaires pertinents dans le code. Les gros documents séparés peuvent se périmer si personne ne les entretient; une vérification régulièrement exécutée révèle plus facilement sa divergence avec le comportement.

Lorsqu’un bogue atteint la production, la démarche décrite chez Algosys commence par un test qui le reproduit. Le test échoue avant le correctif, puis réussit après. Il conserve la connaissance du problème et protège contre sa réintroduction. Sa valeur est forte parce que le scénario a réellement échappé aux contrôles et qu’une zone complexe peut provoquer une nouvelle erreur lorsqu’on y revient.

4.6 Un vert peut cacher un mauvais test

Un test qui passe alors que le comportement attendu n’a pas encore été implémenté mérite une enquête. Il peut invoquer la mauvaise chose, vérifier une condition sans rapport avec le besoin ou ne rien vérifier de pertinent. Sa réussite donne un faux sentiment de sécurité, comparable aux analogies de ceinture ou de coussin protecteur inutilisable évoquées pendant la séance.

Le rouge avant le vert est une façon de vérifier que le scénario peut détecter l’absence du comportement. Cela ne prouve pas que tous les scénarios nécessaires existent, mais évite de prendre une vérification toujours verte pour une preuve suffisante. Le contre-exemple de la salutation codée en dur montrera une autre limite : un test peut être réellement exécuté tout en restant trop étroit.