Dev.Agile.Stories

Quelques rappels historiques :

• Kent Beck est l’inventeur du TDD (Test Driven Development)
• En 1999 il lance officiellement la méthode Extreme Programming (XP) dont il est co-inventeur
• En 2001 il fait partie des 17 signataire du manifeste agile.

Les principes généraux du TDD :

• on a au départ un certain niveau de qualité de code
• on écrit le test tout en générant le squelette du code testé à l’aide de l’ide
• on vérifie que le test échoue
• on complète le code jusqu’à ce que le test passe
• on refactore le code pour maintenir le niveau de qualité (on peut même faire mieux!) que l’on avait avant d’écrire le test

J’ai vécu plusieurs étapes avant d’utiliser TDD :

Premier étape : pas de tests automatisés avec peu de refactoring : le logiciel est exploitable à court terme mais la qualité et la maintenabilité ne font que diminuer, les évolutions sont de plus en plus coûteuses et de moins en moins de développeurs sont motivés pour faire évoluer le logiciel

Deuxième étape : Pas de tests automatisés mais beaucoup de refactoring : le logiciel est exploitable à moyen terme et colle bien au besoin, la qualité est correcte bien que non homogène mais cela dépend d’une connaissance exhaustive du code, de beaucoup de courage des équipes, les régressions sont inévitables, la confiance des nouveaux arrivants est faible pour bouger le code, le turn-over des équipes est très pénalisant.

Troisième étape : une conception technique documentée sous forme de spécifications techniques détaillées (STD) formalisée en UML avant de coder et des tests écrit après avoir coder : le logiciel est exploitable, robuste, de bonne qualité, l’évolutivité est correcte compte tenu de la couverture des tests mais les délais augmentent à cause de la phase de STD, les STD sont très difficiles à maintenir, le code ne fait que s’éloigner des STD, les équipes sont peu motivés pour écrire des tests après le code, les itérations rapides ne sont pas privilégiés.

Et enfin : le TDD avec beaucoup de refactoring : le logiciel est tout le temps exploitable, flexible, la qualité est constante, les livraisons rapides, le niveau de confiance élevé grâce au harnais de test, le turn-over est supportable à condition de ne pas changer toute l’équipe d’un seul coup, mais il faut aimer écrire du code, être courageux et une réelle volonté de ne « rien lâcher », les valeurs humaines font la différence et c’est finalement assez difficile à prévoir.

En conclusion,  j’aime bien écrire du code sans « sur design » et avec un minimum de dette technique, le TDD m’a donc logiquement réussi et constitue une amélioration par rapport à mes expériences précédentes. Cela dit la route est encore longue et l’innovation toujours nécessaire afin de rendre l’écriture de code toujours moins fastidieuse et toujours plus proche de l’expression du besoin.