Quel rapport entre les sophistes chez les Grecs et les développeurs utilisant le TDD ?
Remarque: Ce billet est volontairement provoquant.
Dans [2], les auteurs indiquent que le sophiste est un type
d'homme à mètis:
Le triomphe insolent d'Antiloque qui devant les chevaux plus rapides
de Ménélas n'a rien à envier à "la prestigieuse puissance" du sophiste qui,
tenant deux discours opposés sur chaque question, réussit à faire du discours
le plus faible le plus fort, celui qui contre toute attente terrasse
par une prise irrésistible.
Dans les dialogues de Platon, Socrate questionne plusieurs sophistes se vantant
d'avoir réponse à tout. Au fil des questions de Socrate, le sophiste interrogé
change d'avis, se contredit lui-même, ce dont Socrate s'amuse largement.
L'important pour le sophiste est de paraître savoir, d'avoir réponse à tout
en usant de rhétorique pour l'emporter sur ses contradicteurs, en déployant
mille ruses pour contrer leurs arguments. La vérité ne l'intéresse pas.
Le Test Driven Development (TDD) ou en Français développement piloté par les tests
est une technique de développement de logiciel qui préconise d'écrire les tests
unitaires avant d'écrire le code source d'un logiciel.
Je pratique peu l'écriture de tests avant d'écrire le code, pour de multiples raisons,
par exemple à cause des structures de données en jeu qui deviennent rapidement complexes
et rendent malaisé d'écrire les jeux de tests. Il se peut également que j'utilise des nombres
aléatoires dans des algorithmes. Bien qu'il soit possible de générer toujours les mêmes nombres
pour les besoins d'un test, est-ce encore un test pertinent dans ce cas ? Il y a également le problème
de l'oracle, qui certes se pose moins pour les tests unitaires que pour les tests englobant
plusieurs fonctions.
Si je suis d'accord avec le fait d'écrire des tests avant le code lorsque c'est possible,
la démarche prônée par la méthode ne me semble pas pertinente en général: Il s'agit d'écrire un
premier test puis de coder pour le satisfaire; ensuite ajouter un test, puis rajouter
ou modifier du code pour passer le second test, et ainsi de suite.
Cette démarche fait ressembler le développeur à un sophiste, avec chaque nouveau test
ayant le même effet qu'une question de Socrate: le développeur trouve une réponse pour le premier
test en pondant un code; le second test échoue, il modifie son code pour passer le second test.
Le troisième test échoue, il revoit alors sa copie pour ajouter un cas, et ainsi de suite
jusqu'à passer tous les tests.
L'intelligence pratique du développeur peut lui permettre
de passer tous les tests proposés et de sortir en quelque sorte victorieux, tout comme
le sophiste qui parviendrait à contrer tous les arguments de ses contradicteurs.
Mais est-ce que le fait de passer tous les tests est suffisant? Est-ce que réfléchir à la
façon de passer un test est la bonne façon de réfléchir à une fonction?
Ne serait-il pas préférable de réfléchir dès le départ à la façon dont la fonction peut
effectuer le bon calcul? aux informations nécessaires à ce calcul? Est-ce que le
TDD ne retarde pas le moment de se poser les questions qui viendront de toutes façons
lorsque tous les expédients auront été tentés pour passer les tests?
De plus, écrire du code pour un test tout en sachant que le code ne marche
que pour ce cas me semble pour le moins ridicule.