Dans quel cas devrait-on utiliser le développement piloté par les tests ?

Dans quel cas devrait-on utiliser le développement piloté par les tests ?
« le TDD est un outil, pas une religion », déclare un développeur

Thomas Bandt, développeur et entrepreneur, a récemment écrit un billet de blog où il se demande pourquoi les gens qui parlent du développement dirigé par les tests (TDD : Test Driven Development) se partagent souvent en deux groupes : « les fondamentalistes qui exigent qu’aucune ligne de code ne doive être écrite sans un test, et les renieurs, ceux qui se refusent carrément à utiliser le TDD ».

Dans son article, il raconte son expérience personnelle, où il avait réalisé plusieurs projets, dont certains, avec un développement TDD, et d’autres sans TDD. Ce qu’il avait remarqué, c’est qu’aucun de ces projets n’avait échoué. « Pour que les choses soient testables, vous avez besoin de plus d'infrastructures et souvent un niveau d'abstraction plus élevé, même pour les choses les plus simples ». Toutefois, ceci même s’il est souhaitable dans certains cas complexes, n’est pas justifié pour les projets simples et moins ambitieux, continu-t-il.

Il explique ce point de vue par le rapport coût-bénéfice : « en couvrant des choses simples comme une action de contrôleur ASP.NET MVC qui retourne simplement une vue, ou une directive AngularJS qui vient manipuler un élément DOM, la valeur que vous obtenez en retour pour vos tests automatisés est beaucoup trop faible par rapport à l'énorme effort que vous avez à faire au lieu de simplement tester manuellement », surtout lorsque cela implique de « refactoriser le code d’un test à cause d’un changement de conception ».

Selon lui, il faudrait utiliser le développement piloté par les tests uniquement lorsque l’on veut valider des algorithmes ou des parties critiques d’une application, ou lorsqu’on a des dépendances dont on n’a pas confiance ou qu’on ne connaît pas encore comme, par exemple, une API tierce ou un nouveau provider de base de données.

« Je pense que s’était Steve Sanderson qui avait déclaré sur son blog qu'il utilisait les tests seulement lorsqu’il ne pouvait pas analyser [son code] facilement pour trouver un bug », déclare Thomas Bandt, « et je pense qu'il a raison » finit-il par avouer.

Source : Blog de Thomas Bandt

Et vous ?

:fleche: Que pensez-vous du TDD ?

:fleche: Êtes-vous d’accord avec l’avis de Thomas Bandt ?

Une fois n'est pas coutume, je crois qu'il existe une rubrique plus appropriée pour un tel sujet : http://www.developpez.net/forums/f40...ement-best-of/

Je suis tout à fait d'accord.
J'ai fais parti d'une boîte où il fallait tester chaque fonction de chaque classe, on y passait un temps fou, et je pense que le gain était négligeable.
Les tests n'explosaient que lorsqu'on changeait (volontairement) des choses, et ne finissaient que par nous ralentir (énormément).
(On travaillait avec un FrameWork MVC aussi).

Néanmoins, il faut des tests, mais sur les calculs, les parties importantes, là où on n'a pas le droit à l'erreur.

Mais pour en revenir aux TDD... Je pense du coup qu'avoir une méthodologie seulement pour une partie du dév. et une autre façon de faire pour le reste est suicidaire.
Donc le TDD ne peut s'appliquer que sur une appli. où l'on teste toutes les fonctionnalités.

Donc c'est bien pour toutes les applis sensibles, (calculs importants, vies, sécurité etc... en jeu),
Maintenant pour faire une appli de gestion Web par exemple, même assez poussée, je pense que le TDD est une perte de temps effectivement (même si il faut faire des tests, en maîtrisant sérieusement leur étendue).

Après c'est une question de moyens aussi.

En faite j'ai plus l'impression que tu lances un débat sur 'Test' ou 'pas test' en gros doit t'on atteindre les 100% de couverture ou non. Et non pas TDD vs Tests classiques, ce qui est comme même assez différent.

Personnellement, je suis partisan du TDD et de la couverture à 100%, Le TDD est difficile à mettre en application pour une personne inexpérimenté et impose certaines contraintes d'architecture logicielle, mais une fois dans le bain le test devient rapide à réaliser, il permet de cadrer et d'accélérer le développement. De plus le test fait office de 'contrat' avec le chef de projet.

On se sent ensuite plus en sécurité quand on réutilise des composants, ou bien que l'on fait des montées de versions de librairie, nul besoin de retester l'application 'à la main' en entier à chaque modification, cela prend 2 minutes.

Heu, il n'y aurait pas un gros amalgame entre les tests en général, le TDD et les tests unitaires en particulier, là ?

Pour la partie ASP.NET MVC, il ne faut pas tester chaque fonction, c'est évident : là, ce sont des tests d'interface qu'il faut, alors que lui sous-entend d'utiliser des tests unitaires.

Citation:

---

« Je pense que s’était Steve Sanderson qui avait déclaré sur son blog qu'il utilisait les tests seulement lorsqu’il ne pouvait pas analyser [son code] facilement pour trouver un bug », déclare Thomas Bandt, « et je pense qu'il a raison » finit-il par avouer.

---

Faux : le but des tests est d'assurer la non-régression, donc ça n'a pas grand-chose à voir avec la capacité à analyser le code. Là, nous sommes plutôt dans la qualité de code que dans sa couverture.

On retrouve ici, selon moi, le même problème que celui qui agite l'Agile actuellement : des gens pas forcément compétents sont à l'origine d'abus (en l’occurrence, le tout-tester avec des tests unitaires), sans vraiment savoir de quoi ils parlent, et entraînent une vague de dénigrement de processus ou méthodes qui sont pourtant extrêmement utiles et efficients. Ce sont ces abus qu'il faut chasser, pas l'ensemble de la méthodologie.

Citation:

---

Envoyé par Bono_BX

Citation:

---

« Je pense que s’était Steve Sanderson qui avait déclaré sur son blog qu'il utilisait les tests seulement lorsqu’il ne pouvait pas analyser [son code] facilement pour trouver un bug », déclare Thomas Bandt, « et je pense qu'il a raison » finit-il par avouer.

---

Faux : le but des tests est d'assurer la non-régression, donc ça n'a pas grand-chose à voir avec la capacité à analyser le code. Là, nous sommes plutôt dans la qualité de code que dans sa couverture.

---

:calim2: Je ne comprends pas! Qu'est ce qui est faut? B raconte son expérience et l'appui par une expérience de A, toi tu dis faux. Donne plutôt les limites de leurs expériences.

Secondo:

Citation:

---

le but des tests est d'assurer la non-régression

---

J'ai aussi envie de crier Faux :aie:. Mais je te laisse une chance de t'expliquer :mouarf:

La non-régression suppose une phase d'évolution ou de mise à jour d'un logiciel, ou même une certaine étape dans le processus de développement! Et là on veut se rassurer que tout ce qui fonctionnait continue de bien fonctionner. Mais ça aussi ce n'est qu'un nom que l'on donne aux tests à un stade précis du cycle de vie d'un logiciel. Avant le test de non-régression, il y a les tests unitaires (et biens d'autres) pour se rassurer que les fonctionnalités développées donnent les résultats attendus. assurer la non-régression est l'un des buts des tests, mais pas le but.

J'espère qu'il n'y aura pas une chaîne de Faux :aie:

Pour finir, il y a ce que l'on appelle en agriculture des expériences paysannes; parlant des paysans qui n'ont aucune formation professionnelle mais qui à force de cultiver de la tomate par exemple (ce qu'ils ont appris dans le tas, question de se débrouiller et d'avoir un gagne pain) finissent par apprendre et à obtenir des super récoltes dans des contextes où des ingénieurs agronomes qualifiés et diplômés échoueront. L'expérience de quelqu'un d'autre peut toujours nous apporter quelques choses, inutile de jouer au connaisseur et de s'enfermer dans une approche par ce qu'on l'a apprise à l'école ou par ce qu'on l'a expérimenté.

Citation:

---

« Je pense que s’était Steve Sanderson qui avait déclaré sur son blog qu'il utilisait les tests seulement lorsqu’il ne pouvait pas analyser [son code] facilement pour trouver un bug », déclare Thomas Bandt, « et je pense qu'il a raison » finit-il par avouer.
Faux : le but des tests est d'assurer la non-régression, donc ça n'a pas grand-chose à voir avec la capacité à analyser le code. Là, nous sommes plutôt dans la qualité de code que dans sa couverture.
Je ne comprends pas! Qu'est ce qui est faut? B raconte son expérience et l'appui par une expérience de A, toi tu dis faux. Donne plutôt les limites de leurs expériences.

---

(Ca fait beaucoup de citation dans des citations :P)
Le "Faux" se rapporte à "il a raison" (sinon ça n'aurait effectivement aucun sens). L'explication suit : il n'utilise pas les tests pour ce qu'ils sont faits. Il obtient peut-être des résultats ainsi, mais ce n'est pas un bon argument pour le sujet de la discussion.

Citation:

---

J'ai aussi envie de crier Faux . Mais je te laisse une chance de t'expliquer

La non-régression suppose une phase d'évolution ou de mise à jour d'un logiciel, ou même une certaine étape dans le processus de développement! Et là on veut se rassurer que tout ce qui fonctionnait continue de bien fonctionner. Mais ça aussi ce n'est qu'un nom que l'on donne aux tests à un stade précis du cycle de vie d'un logiciel. Avant le test de non-régression, il y a les tests unitaires (et biens d'autres) pour se rassurer que les fonctionnalités développées donnent les résultats attendus. assurer la non-régression est l'un des buts des tests, mais pas le but.

---

:weird: Depuis quand les tests unitaires ne font pas parti des tests de non régression ? Ta remarque illustre parfaitement ce que je disais : il y a amalgame et incompréhension entre tests unitaires, tests en général et TDD. Mais j’avoue ne pas avoir bien compris ce que tu as écris, c'est u peu touffu. Peux-tu le reformuler, s'il-te-plaît ?

Citation:

---

Pour finir, il y a ce que l'on appelle en agriculture des expériences paysannes; parlant des paysans qui n'ont aucune formation professionnelle mais qui à force de cultiver de la tomate par exemple (ce qu'ils ont appris dans le tas, question de se débrouiller et d'avoir un gagne pain) finissent par apprendre et à obtenir des super récoltes dans des contextes où des ingénieurs agronome qualifiées et diplômés échoueront. L'expérience de quelqu'un d'autre peux toujours nous apporter quelques choses, inutile de jouer au connaisseur et de s'enfermer dans une approche par ce qu'on l'a apprise à l'école ou par ce qu'on l'a expérimenté.

---

Ca tombe bien, je parle justement d'expérience, et c'est pour cela que je fais la différence entre les différents types de test (et que je dis par exemple qu'il ne faut pas faire de TU sur du MVC). Et pour reprendre ton exemple agricole, si une personne cultive des pommes de terre comme des tomates, elle n'obtiendra pas grand-chose, peu importe qu'elle soit ingénieur agronome ou qu'elle apprenne par l'expérience. Personnellement, on ne m'a jamais appris à faire des tests unitaires ou d'interface à l'école, tout ce que je sais à ce sujet, je l'ai appris sur le tas.
Il ne faut certes pas s'enfermer dans une approche (encore fois, confer ma remarque sur le MVC), mais il faut aussi savoir prendre ce qu'il y a de bon dans les méthodes, car elles résultent elles aussi ... de l'expérience et de l'apprentissage de ceux qui les ont mise en place. Bref, avoir l'esprit critique (sans vouloir t'insulter, c'est une remarque générale).

Citation:

---

Envoyé par Bono_BX

:weird: Depuis quand les tests unitaires ne font pas parti des tests de non régression ? Ta remarque illustre parfaitement ce que je disais : il y a amalgame et incompréhension entre tests unitaires, tests en général et TDD. Mais j’avoue ne pas avoir bien compris ce que tu as écris, c'est u peu touffu. Peux-tu le reformuler, s'il-te-plaît ?(sans vouloir t'insulter, c'est une remarque générale).

---

Ce que je voulais dire est que, test unitaire par exemple n'implique pas forcement test de non-régression; Pour moi non-régression suppose quelque chose qui marchait déjà, et après une mise à jour ou une évolution, on se rassure que l'on a rien bousculé. Cependant l'on peut faire des tests pour s'assurer que le bout de code que l'on vient d'écrire marche et là je ne pense pas que l'on puisse parler de non-régression; mais je sais que dans test de le non-régression on peut inclure les unitaires et tous les autres.

Citation:

---

Envoyé par Bono_BX

sans vouloir t'insulter, c'est une remarque générale

---

:D Je te crois sur parole chère ami, surtout que j'ai rien vu d'injurieux et je sais avoir encore beaucoup à apprendre des TDD!

Je rajouterai un petit point pour parler de tests en TDD et de non-régression.

J'utilise assez souvent le TDD dans mon développement.
C'est donc l'écriture de mes tests qui m'induit l'architecture et le développement de ma nouvelle fonctionnalité.
Donc, déjà, mes tests ne sont pas là pour tester quelqu’une des moindres fonctions de mon nouveau bloque fonctionnel, mais le comportement nominal et au limite de celui-ci vu de l’extérieur (c'est à dire des autres couches du logiciel)
J'écris mes tests en pensant: quelle service doit faire mon module/ma classe/ma fonction pour le reste de l'application.

Je peux bien sur factoriser mon bloque en question, sans devoir impacter fortement mes tests
Et c'est même dans ce cas que mes tests qui était à l'origine fait pour m'aider à développer mon nouveau service devienne des tests de non-régression.
Je suis dans un cas où je reste à fonctionnalité constante mais que je modifie mon algorithme (pour plus de visibilité, pour plus de performance, pour mettre à jours un framework, ...)
De même, si je modifie des bibliothèques génériques à mon application, l'ensemble de mes tests me garantissent que je ne fait pas de régression.
Mes anciens tests me servent alors de garde-fou pour tout évolution sur ce point

Dans la même logique, on peut mettre en place des tests d’intégration pour vérifier sur des scénario simples que les différents bloques fonctionnent bien ensemble.
C'est même tests d'intégrations deviennent également des test de non-régression lorsque l'on souhaite améliorer l'architecture entre les différents bloques ou en modifier un en profondeur.

Par contre, je pense que certain vois les tests de non-régression comme des tests à posteriori.
En effet, dans le cas de code "legacy" (pour pas dire du code tout-pourri-codé-par-quelqu'un-qui-n'est-plus-là-et-que-personne-ne-veux-remplacer) il est interessant de pouvoir à posterieuri ajouter quelque scénario de tests afin de vérifier la non régression de certain scénario ou de contrôler la correction d'ancien bug.
Mais on est plus dans une logique de maintenance logiciel que de développement.

A la réflexion, ça va plus vite de dire dans quelles occasions je ne fais pas de TDD (tests unitaires ou autre échelle) :)

• Prototypage rapide en mode "proof of concept"

• Code boilerplate, répétitif et sans grande logique (mais c'est souvent un signal d'alarme pour mieux factoriser ou générer ce code)

• Couche UI

• Legacy code (évidemment)

J'en profite pour rappeler que TDD comporte une étape de refactoring que tout le monde oublie, mais qui est très efficace en combinaison avec les tests...

Je trouve un peu réducteur d'opposer TDD à "pas de tests du tout". Le débat soulevé par le blog est plutôt "quand faire des tests automatisés ?"

Citation:

---

Envoyé par Laurent 1973

Je rajouterai un petit point pour parler de tests en TDD et de non-régression.

J'utilise assez souvent le TDD dans mon développement.
C'est donc l'écriture de mes tests qui m'induit l'architecture et le développement de ma nouvelle fonctionnalité.
Donc, déjà, mes tests ne sont pas là pour tester quelqu’une des moindres fonctions de mon nouveau bloque fonctionnel, mais le comportement nominal et au limite de celui-ci vu de l’extérieur (c'est à dire des autres couches du logiciel)
J'écris mes tests en pensant: quelle service doit faire mon module/ma classe/ma fonction pour le reste de l'application.

Je peux bien sur factoriser mon bloque en question, sans devoir impacter fortement mes tests
Et c'est même dans ce cas que mes tests qui était à l'origine fait pour m'aider à développer mon nouveau service devienne des tests de non-régression.
Je suis dans un cas où je reste à fonctionnalité constante mais que je modifie mon algorithme (pour plus de visibilité, pour plus de performance, pour mettre à jours un framework, ...)
De même, si je modifie des bibliothèques génériques à mon application, l'ensemble de mes tests me garantissent que je ne fait pas de régression.
Mes anciens tests me servent alors de garde-fou pour tout évolution sur ce point

Dans la même logique, on peut mettre en place des tests d’intégration pour vérifier sur des scénario simples que les différents bloques fonctionnent bien ensemble.
C'est même tests d'intégrations deviennent également des test de non-régression lorsque l'on souhaite améliorer l'architecture entre les différents bloques ou en modifier un en profondeur.

---

Merci d'avoir si bien expliqué ce que je pensais réellement :P

Ca aurait pu être intéressant si le mec avait capté que l'objectif de TDD n'est pas de tester son code...
Mais bon... les idées reçues ont la vie dure...

Je pense que la pièce centrale de son argument est justement le fameux "rapport coût-bénéfice".
Celui-là même qui m'a poussé a fortement délaisser les tests unitaires au profit des tests d'intégration qui sont moins souvent intrusifs et moins rapidement invalidés par les opérations de refactoring. C'est particulièrement le cas quand on utilise des sources de données, il est parfois utile de pouvoir tester toutes les couches de son code par des appels haut niveau.