7. Adopter le TDD sans attendre un projet parfait
7.1 Adhésion de l’équipe et jugement professionnel
La démarche doit être comprise et adoptée par les développeurs pour devenir durable. Un membre convaincu peut commencer à la pratiquer et montrer les résultats. Quand les collègues voient une livraison plus sereine, moins de stress et des horaires soutenables, l’adoption peut devenir contagieuse.
La direction doit également comprendre l’investissement et ses bénéfices. Christian Desrosiers insiste sur le rôle professionnel du développeur : ses décisions techniques doivent reposer sur des arguments et sur son expertise. Une personne diplômée reste débutante, mais possède déjà des connaissances spécialisées; l’expérience permet ensuite de prendre de meilleures décisions plus rapidement.
Une croyance de la direction selon laquelle les tests ne servent à rien ne remplace pas cette analyse. L’intervenant défend l’autonomie technique et évoque même la possibilité de travailler ailleurs si l’opposition devient insurmontable. Ce conseil reflète sa position sur la responsabilité professionnelle et le milieu de travail.
7.2 Un logiciel existant ne devient pas rétroactivement TDD
On peut commencer sur un produit ancien, mais pas transformer son histoire en développement initialement piloté par les tests. Le code patrimonial a parfois fonctionné longtemps sans protection automatisée; le remanier sans besoin peut créer un risque nouveau.
La grande réécriture comporte elle aussi un risque : l’équipe travaille longtemps avant de retrouver toutes les fonctions, pendant que le marché continue d’évoluer. Le conférencier cite Netscape pour l’illustrer. Cette référence est un exemple raconté dans la séance, pas une analyse indépendante et exhaustive des causes historiques.
Le conseil pratique est donc de commencer, avec un esprit ouvert, sans attendre une occasion idéale ni décider que tout doit être remplacé immédiatement.
7.3 La transition progressive et la règle du Boy Scout
La stratégie présentée suit cinq gestes complémentaires :
- Écrire le nouveau développement en TDD.
- Ajouter des tests lorsqu’une modification ou un correctif exige d’entrer dans une ancienne zone.
- Éviter d’attaquer sans bonne raison un vieux comportement non protégé.
- Profiter d’un besoin réel pour extraire une portion mal segmentée, la rendre lisible et testable, puis la reconnecter au reste.
- Accroître ainsi la couverture et la qualité du découpage au fil du travail.
C’est l’application de la règle du Boy Scout : laisser la zone meilleure qu’à l’arrivée. Elle justifie une amélioration proportionnée au passage, pas une refonte illimitée à chaque correction.
Chez Algosys, obtenir une couverture convenable a pris plus de deux ans, selon la diapositive. La taille et l’état du logiciel influencent ce délai. Le processus exige de la continuité; l’absence de résultat complet le premier jour n’est pas une raison de ne pas commencer.
7.4 Caractériser le comportement actuel ne prouve pas sa justesse
Des tests générés à partir du code peuvent enregistrer ce qu’il fait actuellement. Ce sont des tests de caractérisation : ils signalent un changement de comportement, mais ne prouvent pas que ce comportement satisfait l’intention d’origine.
Si le code contient un bogue, le test généré peut faire de ce bogue son attente. Corriger le produit fait alors échouer la vérification, parce que le comportement a changé. Il faut une connaissance de l’exigence pour décider si le nouveau résultat est meilleur ou constitue une régression.
La différence est donc celle entre « rester identique » et « faire la bonne chose ». L’autogénération et l’IA ne suppriment pas cette distinction. La caractérisation peut protéger une transition, mais ne remplace pas la définition du besoin et le jugement qui permet de qualifier un résultat.