« Le TDD est mort » pour le créateur de Ruby on rails
Une position qui divise la communauté agile

Le , par Arsene Newman, Expert éminent sénior
« Le TDD est mort ? Ou pas ? » Telle est la question qui taraude l’esprit de la communauté agile en ce moment, vu l’importance du TDD (Test Driven Development – Développement piloté par les tests) dans l’une des méthodes agiles les plus réputées : la méthode XP.

À l’origine de ce débat houleux, David Heinemeier Hansson (DHH) auteur de Ruby on rails et fondateur du Basecamp et ses deux posts intitulés : « TDD is Dead – Long Live Testing » et « Test-induced design damage».

Dans les faits, DHH critique ouvertement le TDD en notant certaines mauvaises pratiques telles que :
  • Concevoir le modèle de son application à partir des tests unitaires n’est pas bénéfique.
  • Trop se focaliser sur les tests unitaires ne permet pas de concevoir de bons systèmes, de plus cela fait oublier généralement les tests systèmes.
  • Les développeurs pensent que le développement logiciel est une science, alors que cela ressemble plus à de l’écriture et à la créativité.


Les critiques à son encontre n’ont pas tardé à fuser de toute part et dans tous les sens, mais une chose est sure, les réponses ont mis l’accent sur la nécessité d’appliquer le TDD de manière pragmatique.

À titre d’exemple, Robert Martin, développeur logiciel de renom, estime pour sa part que : « si l’on ne fait pas de TDD ou quelque chose d’aussi efficace, alors on devrait se sentir mal ». Il explique aussi pourquoi les développeurs ont recours au TDD :
  • Le TDD se traduit par moins de débogage.
  • Les tests font office de documentations exactes, précises et sans équivoque au plus petit niveau du système.


D’autres ont répondu à cette critique dans un nouveau post. C’est le cas de Gergely Brautigam qui a posté un article intitulé « TDDD is Dead – Not really ». Ce dernier explique que le TDD ne peut être mort avec autant d’adeptes et qu’à l’image d'autres concepts informatiques, cela ne peut avoir lieu. Il estime que le TDD pourrait évoluer vers quelques choses de nouveau, de mieux comme beaucoup d’autres concepts en informatique.

Aussi, pour Gergely Brautigam, il est important d’avoir des tests à différents niveaux même si de telles pratiques sont rarement appliquées vu le rythme de développement effréné et le stress que subissent les développeurs, ce qui donne lieu à des négligences en matière de qualité de code.

Enfin, un autre intervenant, Gil Zilberfeld, cite un passage du manifeste agile : « nous découvrons de meilleures façons de développer des logiciels en les faisant et en aidant les autres à le faire . Un passage lourd de sens, comme pour dire que le TDD n’est qu’un outil et une manière de faire parmi tant d’autres après tout.

Et vous ?

Que pensez-vous du TDD ?

Pensez-vous que le TDD est un concept révolu ?


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de transgohan transgohan - Expert confirmé https://www.developpez.com
le 09/06/2014 à 15:39
Concevoir le modèle de son application à partir des tests unitaires n’est pas bénéfique.


Il y a vraiment des projets où c'est appliqué ?
C'est comment avoir un projet mort-né...
Le test unitaire n'est pas représentatif d'un logiciel, il n'est représentatif que d'une fonction dans le code (et je fais bien le distingo entre fonction du code et fonctionnalité du système !).

C'est comme vouloir concevoir une maison à partir des spécificités d'une pierre...
A l'époque des hommes des cavernes ça marchait sans doute...
Mais à notre époque c'est construire la pire maison qui soit en se limitant à cela.
Avatar de Grimly Grimly - Membre averti https://www.developpez.com
le 09/06/2014 à 16:59
@transgohan :

Oui c'est appliqué
C'est un bon moyen d'entretenir des tests car personne n'aime rédiger des tests unitaires sur un programme qu'il a lui même écrit ou qu'un autre a écrit avec ses pieds.
Avoir des tests veux dire que la plupart des régressions sont perçues à l'avance.

C'est très difficile à appliquer car personne n'aime les tests, du coup il faut un responsable technique qui ait les c***lles de l'imposer sur le projet et de refuser les codes qui ne sont pas nécessaire pour faire passer des tests.
Avatar de TheLastShot TheLastShot - Membre averti https://www.developpez.com
le 09/06/2014 à 17:13
Il n'y a que moi que ça énerve cette mode (Je dis mode parce que depuis un petit moment il y en a de plus en plus, mais le phénomène date surement) du développeur à la science infuse. J'ai l'impression qu'à partir du moment où quelqu'un a fait UN truc qui marche il détient LA vérité suprême et unique, comme si c'était le messie... "Machin pense que le TDD est mort", "Bidule affirme que dans 10 ans truc sera enterré", "Chubaka prédit la fin du langage iWok d'ici la fin de l'année".

En ce qui concerne les TDD je pense que c'est un très bon moyen de s'assurer de la fiabilité du code et de repérer les éventuels erreurs lors du refactoring.
(Exemple de process : on écrit 10 fonctions avec les tests associés. Par la suite quelqu'un touche au code sans vérifier que les tests étaient toujours valide. On revient à notre code en écrivant une nouvelle fonction F qui utilise plusieurs des fonctions précédente et on se rend compte que celle-ci plante... Grâce au test on peut trouver (plus ou moins) directement ce qui ne fonctionne pas, alors que sans les tests on doit débugger, mettre les mains dans le cambouie sans savoir ou on va, ce qui peut prendre plus de temps).

Le vrai problème c'est qu'il y a beaucoup de "mauvais" codeur qui préfère éviter de faire des tests (ou qui ne savent simplement pas les faire) et qui se retrouve au final à perdre plus de temps quand il faut corriger le code...
Avatar de abelar_s abelar_s - Membre habitué https://www.developpez.com
le 09/06/2014 à 19:13
Oui, ce sont des titres grandioses pour du linkbait et du "viral" facile.
Ce n'est pas le premier à faire de la provoc pour se faire entendre

Par contre, ça a lancé une excellente discussion avec Kent Beck, Martin Fowler et DHH: #isTDDdead sur Google+ :
https://plus.google.com/u/0/events/c...4h4d8mejmat98o

Bon visionnage si vous aimez les vidéos ! (je préfère le texte ^^)
Avatar de Fanvan Fanvan - Membre actif https://www.developpez.com
le 09/06/2014 à 19:14
Citation Envoyé par TheLastShot  Voir le message
Il n'y a que moi que ça énerve cette mode du développeur à la science infuse.

Non, il n'y a pas que toi que ça énerve, mais ça dépasse largement la sphère du microcosme des développeurs, et il va falloir qu'on s'y fasse. Un coup de gueule un peu bien tourné sur un blog ou une déclaration un rien provo et iconoclaste, qui seraient passés inaperçus il y a 20 ans bénéficient immédiatement de la caisse de résonance des réseaux sociaux. C'est épuisant de vivre dans un monde du "untel a dit", mais on y est et il faut vivre avec.

Ça m'énerve d'autant plus que des arguments comme "Les développeurs pensent que le développement logiciel est une science, alors que cela ressemble plus à de l’écriture et à la créativité.", ce n'est pas un argument en soit, et ce n'est pas une position défendable si ce n'est pas étayé par des arguments, sans folklore et sans romantisme déplacé. Ce que je ne comprends pas non plus, c'est cette fulgurance qui lui fait passer du constat : "je ne laisse pas mon développement être guidé par des tests, et tout le monde devrait faire pareil" à "ça va pas être facile de vivre dans un monde non test-driven, mais heureusement, rails est là pour nous secourir." J'exagère à peine. Comme si une technologie pouvait solutionner un problème d'ingénierie fondamentalement transversal auquel toutes les technologies sont confrontées. Ce genre de maladresse, qui tient de la maxime publicitaire, jette une ombre sur le propos.
Avatar de _skip _skip - Expert éminent https://www.developpez.com
le 09/06/2014 à 20:11
Personnellement, je suis assez d'accord avec son point. J'utilise plutôt une méthode qui consiste à faire du prototypage, une sorte de POC, puis à refactorer et créer des tests après la validation. Et je crois que c'est logique de penser que le TDD ne correspond pas à cette façon de travailler. Je ne vais pas jusqu'à dire que c'est une mode, c'est une méthode comme les autres, ce qui signifie qu'elle se prête bien à certaines situations et moins bien à d'autres . Le problème c'est que pour tout ce qui est méthodologie agile et autres trucs mainstream, les adeptes sont juste extrêmement dogmatiques.

Il condamne notamment l'interdiction d'avoir recours à des opérations lentes (lire un fichier, interroger une DB). Je reconnais sans difficulté qu'il faut l'éviter si possible, le problème c'est que souvent, c'est un compromis. Tester même succinctement une application qui utilise une base de donnée sans faire de véritables requêtes, c'est assez complexe. Ca peut vous demander d'avoir une abstraction très élevée et de concevoir beaucoup de mock objects. Il suffit d'essayer de mocker un simple "panier d'achat" en mémoire, faisant intervenir différentes entités (Produits, Inventaire etc...) pour se rendre compte que ça demande un paquet de code à la main et que rendre ce type de test possible a aussi des implications sur la conception. Ces tests sont pas forcément écrits une fois pour toutes, ils peuvent demander une maintenance si vous refactorez.
Le danger lorsqu'on veut du tout TDD, c'est de complexifier trop son architecture pour les besoins des tests unitaires, puis de s'enfoncer dans le micro-test. Car le problème qui devient évident lorsqu'on teste une application basée sur une source de données externe, c'est que même si les tests passent, on sait jamais si ça passe tant qu'on ne l'a pas exécutée pour de vrai. A ce moment là, est-ce que ça vaut la peine d'avoir recours intensif au mock si c'est beaucoup de boulot et qu'au final ça prouve pas grand chose??? C'est encore plus vrai si vous utilisez des ORM, pouvez-vous garantir que vos mocks se comportent comme les objets réels (style proxy hibernate)?

Cela nous amène à un autre de ses points, il y a des choses (beaucoup de choses en fait), ou le mieux c'est clairement de se contenter de tests d'intégration de haut niveau. Laisser tomber le test "classe par classe" puis tester des "actions" impliquant plusieurs classes, de véritables transactions qui testent aussi bien les couches métier que les couches inférieures (par exemple accès aux données) sur lesquelles elles reposent. Ce sont des tests plus lourds, longs à exécuter, mais ils sont très proches de la réalité. L'étape plus haut, ce sont les tests pratiqués directement sur l'interface utilisateur, style selenium, qui peuvent aussi avoir un rôle complémentaire intéressant.
Je cite son post en rapport avec ce point :

I rarely unit test in the traditional sense of the word, where all dependencies are mocked out, and thousands of tests can close in seconds. It just hasn't been a useful way of dealing with the testing of Rails applications. I test active record models directly, letting them hit the database, and through the use of fixtures. Then layered on top is currently a set of controller tests, but I'd much rather replace those with even higher level system tests through Capybara or similar.

I think that's the direction we're heading. Less emphasis on unit tests, because we're no longer doing test-first as a design practice, and more emphasis on, yes, slow, system tests. (Which btw do not need to be so slow any more, thanks to advances in parallelization and cloud runner infrastructure).

Je suis 100% d'accord avec ça, tester les opérations au niveau transaction métier, voire au niveau utilisateur, il y a que ça de vrai. Ce sont des tests souvent raisonnablement faciles à écrire et à maintenir vu qu'ils se soucient assez peu de ce qui se passe sous le capot, ainsi vous pourrez refactorer les couches basses sans réécrire la moitié du code de test. Peut être long à exécuter (genre chargement d'un script DB initial qui peut prendre quelques secondes), mais au moins les résultats sont la vérité vraie.
Est-ce que pour autant on devrait plus faire de test unitaires (au sens test de classe)? Non du tout, j'y ai recours assez souvent quand je teste des algos pointus qui doivent absolument être blindés. Il m'arrive même d'appliquer le TDD pour ceux-ci. Donc je le répète :

  • oui pour le test en général
  • oui pour le test unitaire
  • non pour le micro-test systématique
  • non pour l'obligation stricte d'écrire les tests avant


Après qu'on veuille imposer à un débutant qu'il écrive les tests avant pour le forcer à mener la réflexion sur l'architecture passe encore. Mais l'imposer à un professionnel chevronné, c'est encore du dogmatisme. Il faudrait qu'on commence à comprendre que dans ce métier, il y a pas de standards qui tiennent. On résout des problèmes en prenant des aides partout où on en trouve, que ce soit des outils, des méthodologies, des techniques ou des idées.
Avatar de transgohan transgohan - Expert confirmé https://www.developpez.com
le 09/06/2014 à 20:37
Citation Envoyé par Grimly  Voir le message
@transgohan :

Oui c'est appliqué
C'est un bon moyen d'entretenir des tests car personne n'aime rédiger des tests unitaires sur un programme qu'il a lui même écrit ou qu'un autre a écrit avec ses pieds.
Avoir des tests veux dire que la plupart des régressions sont perçues à l'avance.

C'est très difficile à appliquer car personne n'aime les tests, du coup il faut un responsable technique qui ait les c***lles de l'imposer sur le projet et de refuser les codes qui ne sont pas nécessaire pour faire passer des tests.

Non mais je suis d'accord pour coder des tests avant de concevoir l'application.
Mais je suis absolument contre le fait de faire une application modélisée à partir de tests unitaires !
C'est aberrant... Car c'est faire de la conception au niveau le plus bas.
Autrement dit c'est bien pire que du cycle en V.
Pour caricaturer c'est en gros au testeur de faire toute l'architecture et la modélisation de l'application finale.
Cela ne vous choque pas ?

Si vous devez avoir vos tests unitaires avant de coder quoi que ce soit c'est que vous avez fait toute la conception jusqu'au niveau le plus bas. Vous avez pensez à la moindre classe, la moindre fonction, le moindre opérateur... C'est une folie !
C'est complètement anti-agile c'est du cycle en V... (et encore, jamais vu de cycle en V aussi poussé...)
Avatar de azias azias - Membre éclairé https://www.developpez.com
le 10/06/2014 à 0:39
Citation Envoyé par Arsene Newman  Voir le message
Dans les faits, DHH critique ouvertement le TDD en notant certaines mauvaises pratiques telles que :
  • Concevoir le modèle de son application à partir des tests unitaires n’est pas bénéfique.
  • Trop se focaliser sur les tests unitaires ne permet pas de concevoir de bons systèmes, de plus cela fait oublier généralement les tests systèmes.
  • Les développeurs pensent que le développement logiciel est une science, alors que cela ressemble plus à de l’écriture et à la créativité.

Il me semble qu'il fait une petite confusion, non? Par définition les tests unitaires ne sont pas fait pour s'appliquer au niveau application/système mais au niveau le plus bas. Contrairement aux tests d'intégration qui eux ne devraient d'ailleurs pas être fait par les développeurs.

Dans ma pratique, les tests unitaires peuvent servir à deux choses: à vérifier le bon comportement de la fonction (ou du composant, du module, de la classe...) par rapport à la spec, ou à rechercher un bug. C'est un peu la même chose techniquement, mais la construction des cas de tests ne sera pas la même, le contexte et la motivation non plus.

Par ailleurs je trouve aussi que la réutilisation des tests unitaires est intéressantes pour comparer deux versions d'une même fonction. D'une part évidemment pour vérifier que les bugs sont bien corrigés et que le reste des fonctionnalités est inchangé, mais aussi pour faire des tests de performance par exemple. Utile quand on récupère des "morceaux" dans le stock open source, choisir entre bibliothèque ou une autre, etc.

Par ailleurs je ne suis pas d'accord avec lui quand il dit que le développement logiciel n'est pas une science. D'une part je ne vois pas la contradiction: la science c'est de la créativité, certain diront même qu'il y a de l'art dans la science. D'autre part la question est de savoir ce qu'on fait de cette créativité? Si on la laisse à l'état brut, on fait n'importe quoi. C'est ce que fait un mauvais développeur. Si on s'en sert comme un point de départ, en organisant les choses de façon rationnelle, en faisant l'effort de comprendre le problème et en étant capable de justifier ce qu'on fait, c'est de la science. Il me semble que c'est ce que fait un bon développeur.

Là où je le rejoindrais peut-être (je ne suis pas certain d'avoir compris le fond de sa pensée) c'est que se fier uniquement aux tests serait une erreur. Sans faire mon serment habituel sur les méthodes formelles, il est tout simplement impossible de tester entièrement une fonction. Ne serait-ce qu'un additionneur 64bits sur nos processeurs actuels. Ça nous fait 2*2^64 cas de tests. Rien que le temps de les réaliser sur un processeur 2Ghz par exemple (disons 2^21 Hz pour simplifier), ça nous fait 2^44 secondes, soit plus de 557 millénaires pour une fonctionnalité aussi simple, et encore il reste à faire la vérification du résultat sur chaque cas de test...

Bref, le test est très utile mais il ne doit pas empêcher de rester intelligent, en particulier dans la façon de faire les tests, sinon on va facilement dans le mûr.
Avatar de theMonz31 theMonz31 - Expert confirmé https://www.developpez.com
le 10/06/2014 à 8:33
oui enfin, le développement ça doit rester fun...

Alors, moi, personnellement, je n'utilise aucune méthode particulière et je m'en porte formidablement bien dans ma tête...

Je n'ai pas un process à respecter à la lettre... et comme je déteste que l'on m'impose quelque chose, je fais à ma sauce des logiciels dont mes
clients sont forts content...

J'aime autant faire des tests fonctionnels et basta...

Bien sur, quand je code mes fonctions, mon expérience fait que j'anticipe (surement une partie) des situations ou il pourrait y avoir des soucis
et donc code le comportement sans avoir à passer un test qui me garantirait que j'ai couvert tous les cas...

Et quand bien même, pourquoi "couvrir" toutes les situations... je ne fais pas de l'embarqué aéronautique.. (j'ai eu fait... je connais, c'est chiant)...

Bref, TDD ou pas TDD... on s'en fout.. l'essentiel est que coder soit Fun, le reste... sinon, on devient des ouvriers à la chaine, contraint par des process...

Apparemment, certains aiment bien celà... Moi, j'suis métal... j'aime pas
Avatar de thierry.pericard thierry.pericard - Membre du Club https://www.developpez.com
le 10/06/2014 à 9:46
Bonjour,

Sauf erreur de ma part, tout logiciel devrait être testé avant recette purement utilisateur. Après, il faut faire la distinction entre pragmatisme et dogmatisme. Dans tous les cas, il devrait exister au final pour un logiciel :

- des tests unitaires sur au moins les fonctions les plus critiques ou les plus compliquées,
- des tests plus "métiers", écrits en utilisant Selenium par exemple, mais ce n'est sans doute pas la seule solution.

Maintenant, s'il faut passer des heures à débugger des tests à chaque version, c'est que les tests sont mal utilisés. A contrario, l'absence de tests unitaires n'est pas une bonne garantie de l'avenir (hormis les cas de logiciels jetables ou de très courtes durées).

Pour terminer, il faut se rappeler que la détection d'une anomalie coûte beaucoup plus chère qu'elle est découverte le plus tard possible.
Offres d'emploi IT
Architecte sécurité des systèmes d'information embarqués H/F
Safran - Ile de France - 100 rue de Paris 91300 MASSY
Ingénieur H/F
Safran - Ile de France - Moissy-Cramayel (77550)
Architecte technique des systèmes d'information H/F
Safran - Ile de France - Évry (91090)

Voir plus d'offres Voir la carte des offres IT
Contacter le responsable de la rubrique Accueil