L'approche TDD permet une programmation sans développement superflu, avec une progression fluide, efficace. Serait-elle avant tout une question de productivité?

Ron Jeffries, un des 3 fondateurs de l'extreme programming, a récemment posté une série de tweets concernant le Test Driven Development.

"Ecrivez un petit test, voyez qu'il ne s'exécute pas, écrivez juste assez de code pour le faire fonctionner, refactorisez le code pour supprimer les doublons et ajouter de la clarté, répétez l'opération jusqu'à la fin.

Pourquoi fait-on cela?"

Ron Jeffries - Twitter

Oui, pourquoi ? Beauté, artisanat, fierté, ... Le TDD est une pratique controversée car coûteuse à mettre en place. Elle a été introduite en 1999 par ce même Ron Jeffries, Kent Beck et Ward Cunningham dans leur livre Extreme Programming Explained.

Comme le rappelle Ron Jeffries dans son tweet, le Test Driven Development (Développement Dirigé par les Tests), est une technique de développement qui impose l’écriture de tests avant même l’écriture de la première ligne de code.

On peut découper le TDD en 6 étapes distinctes :

  1. Écrire un test,
  2. Vérifier qu’il échoue,
  3. Écrire le code suffisant pour que le test passe,
  4. Vérifier que le test passe,
  5. Optimiser le code,
  6. Vérifier que les tests passent toujours.

Popularisée par les craftsmen, cette pratique peine cependant à émerger certainement du au fait qu'elle nécessite une bonne dose de connaissance des bonnes pratiques de développement et de mise en place de tests unitaires. Sans ces connaissances, l'exercice devient périlleux (tests incompréhensibles, tests difficilement maintenables, ...).

Une fois la compétence acquise, il reste tout de même un coût de mise en place de TDD. Mais voilà pourquoi cette pratique reste productive :

  • Le code correspond au minimum nécessaire à la réalisation de son objectif. Il reste simple,
  • Le code est bien conçu, compréhensible et cela aide à aller vite,
  • Le code fonctionne toujours. Il ne se trouve jamais dans un état où il fonctionne presque mais nous ne savons pas très bien pourquoi.

Le code correspond au minimum nécessaire

Démarrer le développement d'un scénario (besoin réel attendu ) en écrivant un test simple et créer le code suffisant pour faire passer ce test au vert, c'est s'assurer de proposer un code minimal.

Qui dit code minimal dit code simple, lisible, maintenable, évolutif...

Le code est bien conçu

Le code est minimal, du fait du point précédent. Même s'il était mal conçu, se serait déjà ça de gagner.

Maintenant, du fait que celui-ci ai été développé pour être consommé par un client (le test) dans un contexte séparé (le contexte du test), le code est découplé du reste de l'application. Il est de ce fait bien conçu.

Il est bien sûr possible de créer de mauvais tests unitaires (qui ne sont d'ailleurs pas toujours unitaires) et que le code résultant ne soit pas forcément bien conçu. Mais en s'assurant à minima de la bonne écriture du test, le code résultant ne devrait pas être si mal que ça.

Comme le disait un architecte de la SGCIB que j’appréciai beaucoup :

"On ne peut empêcher aucun développeur de se tirer une balle dans le pied."

Stéphane Lopez - Architecte SGCIB

Le code fonctionne toujours

Combien de fois cela vous arrive-t-il de vouloir nettoyer du code pour le rendre compréhensible (souvent j'espère) mais que vous n'osez pas car vous avez peur de "tout casser" ?

La mise en place de tests unitaires vous libère de cette peur et vous permet d'améliorer le code en continu. La mise en place de tests unitaires en amont vous aide dès le départ à améliorer votre code en continue sans risque de tout casser : le code fonctionne toujours, ou s'il ne fonctionne plus (test rouge), vous vous en apercevait rapidement.

L'utilisation d'outils comme NCrunch vous permet d'avoir un feedback encore plus rapidement. Grâce à lui, vous êtes averti en continu si le code que vous modifier casse un test.

En résumé

"La lenteur ressentie correspond plutôt à de la fluidité. Aucun développement superflu, une progression fluide, efficace. TDD est avant tout une question de productivité. Il s'agit de fournir le code le plus efficace pour le développement d'une story."

Ron Jeffries - Twitter

Retrouvez ci-dessous le fil de discussion passionnant autour de ce sujet.