Discussion :

[Amine Horseman]

Les bonnes habitudes du développement piloté par les tests
Selon un sénior , on doit obéir à trois cycles durant la phase de développement

Robert C. Martin alias Uncle Bob revient avec un nouveau billet dans sur son blog « Clean Code », avec pour sujet : le Test Driven Development (TDD).
Cette méthode de développement axée sur l’écriture des tests avant le code obéit à trois lois :

• première loi : toujours écrire le test avant d’écrire le code de la fonction testée ;
• deuxième loi : définir dans le test les comportements et les résultats attendus de la fonction testée ;
• troisième loi : écrire dans la méthode testée le code suffisant afin que le passage du test soit un succès.

Le développeur devrait garder ces trois lois à l’esprit pour chaque ligne de code qu’il écrit. Mais selon les explications de Robert Martin, un codeur TDD respecte durant la phase de développement trois autres cycles :

1. Le micro-cycle (Red-Green-Refactor) : répété chaque minute, il se base sur l'idée que « nos esprits limités ne sont pas en mesure de poursuivre les deux objectifs simultanés de tous les systèmes de logiciels, dont un comportement correct et une structure correcte. Donc, le cycle RGR met d'abord l'accent sur le travail de faire correctement le logiciel, avant de se concentrer la structure du logiciel ».
   Les règles de ce cycle sont simples :
   
   • créer une unité de tests ;
   • écrire le code de production qui permet de passer ce test avec succès ;
   • nettoyer le gâchis que vous venez de faire.
   
   
2. Le milli-cycle (Specific/Generic) : répété chaque 10 minutes, se base sur le principe suivant :
   
   • plus les tests sont spécifiques, plus le code devient générique.
   « On dit souvent que la structure à grain fin des trois lois et le cycle Red-Green-Refactor mènent à des optimisations locales ». Ces optimisations locales font parfois que le développeur se trouve « bloqué » à cause du manque de généralisation. Si cela arrive, « la seule solution est de revenir en arrière à travers les tests précédents, les supprimer, jusqu'à atteindre un test à partir duquel il peut prendre un autre chemin ».
   
   
3. Le cycle primaire : répété chaque heure, son objectif est de faire en sorte que les autres cycles nous conduisent bel et bien vers une architecture claire.
   Ainsi, chaque heure, le développeur doit « s’arrêter pour regarder l'ensemble du système » afin de détecter « les limites architecturales » de son logiciel et voir si sa solution suit une logique bien définie.

Source : Clean Code Blog

Et vous ?

Êtes-vous d’accord avec l’avis de Robert Martin ?

Utilisez-vous (ou utiliserez-vous) le Test Driven Development ?

[Angelsafrania]

Je ne comprend pas pourquoi :

plus les tests sont spécifiques, plus le code devient générique.

Qu'est ce qui permet de dire ça ?
Donc dans le milli-cycle, on pète un peu tout ce qu'on à fait, pour amener de la généricité. Et dans le cycle primaire on peut péter pour qu'on ai une archi correcte ?
En gros on nous dit, réfléchissez pas trop, coder et après seulement faite du propre en gros c'est ça ?
[EDIT]
C'est n'est pas une critique juste un constat pour le faite de faire en draft et revoir après.
Je suis comprend l'utilité de développer et d'utilisé les bon design patern qui servent (ca évite de l'anti patern).
[/EDIT]

[Arnaud13]

En gros on nous dit, réfléchissez pas trop, coder et après seulement faite du propre en gros c'est ça ?

Je penses que c'est plutôt dans le sens on optimise après. Je ne sais plus où j'ai lu ça, mais je suis complètement d'accord, le code c'est comme une rédaction. Il faut se relire, changer certaines tournures de phrases, alléger le style par endroit, etc... Dans une copie écrite, on ne doit jamais rendre le premier jet. Pour le code c'est pareil.

[boero-teyssier Greg]

Je penses que c'est plutôt dans le sens on optimise après. Je ne sais plus où j'ai lu ça, mais je suis complètement d'accord, le code c'est comme une rédaction. Il faut se relire, changer certaines tournures de phrases, alléger le style par endroit, etc... Dans une copie écrite, on ne doit jamais rendre le premier jet. Pour le code c'est pareil.

Pour moi l’atout majeur de la TDD et de ne pas à avoir à revenir sur ton code pour effectuer des changements majeurs donc tu dois le panser avant de l’écrire.
Pour reprendre ta métaphore, quand tu fais une rédaction tu écris un plan avant de te lancer dans sa rédaction ? là ton plan ce sont tes tests.

En lisant l’article original, quand il dit de détruire les tests précédant cela ne veut pas dire tous les tests.
Si tu es bloquée dans l’écriture des tests dans cette phase c’est que tu as un problème d’architecture donc pour corriger cela tu dois faire du refactoring ,
en TDD on dit que l’architecture émerge.

[Arnaud13]

Pour moi l’atout majeur de la TDD et de ne pas à avoir à revenir sur ton code pour effectuer des changements majeurs donc tu dois le panser avant de l’écrire.

On est bien d'accord. Je parles d'optimisations, pas de changement du fonctionnement des méthodes.
Je penses qu'on veut dire la même chose, quand tu parles de "refactoring".

[Gulien]

Y a des gens qui ont le temps de faire du TDD en entreprise ?
Ça me parait utopique tout ça (je peux me tromper).

Perso je ne suis pas fan de cette méthode à la base donc ...

[boero-teyssier Greg]

On est bien d'accord. Je parles d'optimisations, pas de changement du fonctionnement des méthodes.
Je penses qu'on veut dire la même chose, quand tu parles de "refactoring".

Ok mais alors si tu respectes le fonctionnement de la TDD ton optimisation tu la fait lors du refactoring quand ton test est passée au vert donc pas besoin de grosses optimisations car tu as écrit le minimum pour que ton test fonctionne

Y a des gens qui ont le temps de faire du TDD en entreprise ?
Ça me parait utopique tout ça (je peux me tromper).

Perso je ne suis pas fan de cette méthode à la base donc ...

moi je l'utilise dans mon projet actuel et je peux te dire que quand tu le fais depuis le début les temps de développement son réduit par exemple le projet que je te parle grâce à la TDD on a gagné 2 mois de développement. Mais il faut bien l'utiliser et surtout le faire avec des personnes qui réfléchissent avant de codée

[Invité]

Je suis de moins en moins convaincu par le tdd.
Je pense que le but premier du tdd c'est de renforcer l'idée d'interfaces claires.
Le fait d'écrire un test unitaire force à imaginer comment on >veut< utiliser sa classe.
Du coup on écrit une classe qui sera dans l'utilisation adaptée à ses besoins.

Ca marche, mais ca fait très extremum local, dans le sens que à un moment donné, il faut refactorer (c'est le cycle de la vie)

Un argument un peu éphémère en premier:
- si la facon dont on a vu notre première utilisation de la classe rentre en conflit avec une deuxième utilisation,
alors on refactore la classe, ET le test en plus, etc...

- si d'un autre côté, on a juste designé l'interface de la classe sans écrire les tests mais juste en les imaginant, alors on ne refactore que l'interface.

Un second argument un peu flou mais plus profond:
Ca me fait penser (l'analogie est quand même douteuse c'est juste un sentiment) aux échecs, le tdd c'est un peu une réflexion tactique, on regarde ce qu'il y a de mieux, on passe à un autre test, on regarde si c'est mieux, moins bien, etc...
Alors qu'on peut imaginer son interface en terme d'autres critères:
1) et si je mettais cette méthode avec celle la elles vont bien ensemble, celle la me plait pas jla mets ailleurs (quand même plus simple quand on a toutes les méthodes en main).
2) Un ptit design pattern par là, une petite analyse de l'interface: mm un peu trop procédurale, pas très spécifique (mothership), etc
bref plein de critères qu'on peut trouver sur le net et qu'il peut être intéressant de vérifier (une réflexion positionale donc) avant de se lancer tête baissée dans chaque test

bref, je dis pas que c'est pas bien, je dis juste que son seul intérêt c'est de forcer une interface facile/ergonomique d'emploi, et d'éviter le code mort/complexité inutile. C'est bien, mais pas forcément le top faut voir un peu plus loin!

[atha2]

Avant toute chose, je tiens à préciser que je ne pratique pas le TDD (ou du moins pas tel qu'il est décrit ici).

Je ne comprend pas pourquoi :
Qu'est ce qui permet de dire ça ?
Donc dans le milli-cycle, on pète un peu tout ce qu'on à fait, pour amener de la généricité. Et dans le cycle primaire on peut péter pour qu'on ai une archi correcte ?
En gros on nous dit, réfléchissez pas trop, coder et après seulement faite du propre en gros c'est ça ?

C'est ce que je comprend de l'approche TDD, on code les tests des fonctionnalités puis ces dernières, et après on regarde l'architecture

C'est n'est pas une critique juste un constat pour le faite de faire en draft et revoir après.

C'est ça, d'abord on code et on revient après dessus pour nettoyer -si on a le temps

Je penses que c'est plutôt dans le sens on optimise après. Je ne sais plus où j'ai lu ça, mais je suis complètement d'accord

Généralement c'est plus pour l'optimisation des performances que de architecture qu'on dit ça. Mais c'est vrai qu'il ne faut pas non rendre générique tout et n'importe quoi. Il faut en avoir identifier le besoin.

, le code c'est comme une rédaction. Il faut se relire, changer certaines tournures de phrases, alléger le style par endroit, etc... Dans une copie écrite, on ne doit jamais rendre le premier jet. Pour le code c'est pareil.

Tout à fait d'accord

Pour moi l’atout majeur de la TDD et de ne pas à avoir à revenir sur ton code pour effectuer des changements majeurs donc tu dois le panser avant de l’écrire.

Sur ce point là, je ne vois pas le TDD de la même façon (j'ai peut-être mal comprit ce que tu voulais dire et/ou TDD), pour moi, le développement des fonctionnalités est dans un premier temps le principal but (pour éviter de se retrouver avec une architecture surdimensionnée). Ensuite seulement, on refactor (en utilisant les fonctions dédiées de nos cher IDE ) pour améliorer (plus générique/objet) là ou il faut. Comme tu le dis dans la suite de ton message :

Si tu es bloquée dans l’écriture des tests dans cette phase c’est que tu as un problème d’architecture donc pour corriger cela tu dois faire du refactoring,

à partir du développement des fonctionnalités (des affinités découvertes et des blocages) :

en TDD on dit que l’architecture émerge.

Y a des gens qui ont le temps de faire du TDD en entreprise ?
Ça me parait utopique tout ça (je peux me tromper).

J’aurai tendance à dire que pour les projets où on n'a pas beaucoup de temps, le TDD peut permettre d'en gagner dans la phase de développement (à condition que les équipes soient formés au TDD). Je sais pas si cela a été mesuré, mais mon sentiment est qu'on aura quelque chose de fonctionnelle et conforme aux besoins plus rapidement (pour la maintenance/évolutivité par contre...).

Ca me fait penser (l'analogie est quand même douteuse c'est juste un sentiment) aux échecs, le tdd c'est un peu une réflexion tactique, on regarde ce qu'il y a de mieux, on passe à un autre test, on regarde si c'est mieux, moins bien, etc...
Alors qu'on peut imaginer son interface en terme d'autres critères:
1) et si je mettais cette méthode avec celle la elles vont bien ensemble, celle la me plait pas jla mets ailleurs (quand même plus simple quand on a toutes les méthodes en main).
2) Un ptit design pattern par là, une petite analyse de l'interface: mm un peu trop procédurale, pas très spécifique (mothership), etc
bref plein de critères qu'on peut trouver sur le net et qu'il peut être intéressant de vérifier (une réflexion positionale donc) avant de se lancer tête baissée dans chaque test

[SEMI-HS]
En tant que joueur d'échecs, je m'étais déjà fait cette comparaison douteuse de l'architecture / position qui permet d'implémenter la fonctionnalité / tactique (notre adversaire étant la loi de Murphy ) et voici mon analyse encore plus douteuse :

• Aux échecs si on ne regarde que la tactique et qu'on ne prend pas en compte les besoins de la position, petit à petit on va se retrouver avec une position perdante (et aux échecs, on n'a pas le droit au refactoring (<=> annuler/modifier mon coup)). En développement, c'est la même chose : plus on attend avant de prendre en compte les besoins de l'architecture, plus le refactoring sera douloureux.
• En n'analysant pas d'un point de vue positionnel, on passe aussi à coté de manœuvres thématiques (attaque sur le roi, attaque de minorité, ouverture du centre). On peut comparer ces dernières aux Design Patterns qu'on peut utiliser pour améliorer l'architecture.
• Quand la position est à notre avantage (avantage d'espace, pièces sur les bonnes cases...), généralement la tactique va tourner à notre avantage. De même, une bonne architecture (structure claire, bonnes relations entre les bon objets), facilitera le développement des fonctionnalités .
• Les fonctionnalités sont validées par les tests, la tactique par le calcul (moins fiable )

[/SEMI-HS]

[guillaume07]

vaste blague ces tests unitaires, quelle perte de temps

[Luckyluke34]

Je ne comprend pas pourquoi :
Qu'est ce qui permet de dire ça ?
Donc dans le milli-cycle, on pète un peu tout ce qu'on à fait, pour amener de la généricité. Et dans le cycle primaire on peut péter pour qu'on ai une archi correcte ?
En gros on nous dit, réfléchissez pas trop, coder et après seulement faite du propre en gros c'est ça ?

De ce que je comprends (ce n'est pas le billet le plus limpide de Uncle Bob), on ne pète pas tout mais on prend de la hauteur pour se rendre compte de ce qu'il faut faire par la suite. Dans le milli-cycle, on s'aperçoit que l'implémentation telle qu'elle est ne va pas pouvoir faire passer tous les tests précédents + le nouveau test, donc on la rend plus générique. Dans le cycle primaire, on lève le nez pour voir qu'on est arrivé aux bornes d'un sous-système et on sait qu'il faut tracer une limite à cet endroit-là.

[Luckyluke34]

bref, je dis pas que c'est pas bien, je dis juste que son seul intérêt c'est de forcer une interface facile/ergonomique d'emploi, et d'éviter le code mort/complexité inutile. C'est bien, mais pas forcément le top faut voir un peu plus loin!

Ca, c'est le premier effet kiss cool : les tests sont le premier client qui va utiliser le code de production, donc on réfléchit plus à la conception d'un point de vue pragmatique/utilisateur de l'API. Mais il ne faut pas oublier les assertions à l'intérieur des tests qui vérifient le comportement du code de production, et serviront de filet de sécurité signalant des bugs pendant toute la suite du processus de développement.

[Mens Pervincet]

plus les tests sont spécifiques, plus le code devient générique.

Je ne comprend pas pourquoi :
Qu'est ce qui permet de dire ça ?
Donc dans le milli-cycle, on pète un peu tout ce qu'on à fait, pour amener de la généricité. Et dans le cycle primaire on peut péter pour qu'on ai une archi correcte ?
En gros on nous dit, réfléchissez pas trop, coder et après seulement faite du propre en gros c'est ça ?
[EDIT]
C'est n'est pas une critique juste un constat pour le faite de faire en draft et revoir après.
Je suis comprend l'utilité de développer et d'utilisé les bon design patern qui servent (ca évite de l'anti patern).
[/EDIT]

Moi je suis plutôt d'accord avec cette assertion, voici mon interprétation:

• Plus un test est spécifique, moins le bloc de code testé est étendu.
• Cela veut dire que les blocs testés sont plus petits et plus nombreux.
• Un bloc testé (et donc testable) est un bloc ayant un contrat clair, une entrée et une sortie bien définies et attendues.
• Ces blocs peuvent donc être réutilisés dans d'autre contextes.

On peut aussi procéder par analogie: on peut construire des formes plus variées, dans des contextes bien plus variés en utilisant des petites briques qu'avec des gros blocs de marbre.

Je ne suis pas forcément un adepte rigoureux du TDD. Cependant étant donné ce que l'on voit comme code quotidiennenement, force est de constater que les tests unitaires constituent un excellent garde-fous contre les "Fourre-tout design pattern" et codes procéduraux aux effets de bords imprévisibles. Le TDD a le mérite d'orienter naturellement le développeur vers du fonctionnel, de réflechir aux entrées / sorties de ses fonctions, ce qui est à mon avis le B-A BA, pas toujours respecté du développeur.

[Angelsafrania]

Moi je suis plutôt d'accord avec cette assertion, voici mon interprétation:

• Plus un test est spécifique, moins le bloc de code testé est étendu.
• Cela veut dire que les blocs testés sont plus petits et plus nombreux.
• Un bloc testé (et donc testable) est un bloc ayant un contrat clair, une entrée et une sortie bien définies et attendues.
• Ces blocs peuvent donc être réutilisés dans d'autre contextes.

On peut aussi procéder par analogie: on peut construire des formes plus variées, dans des contextes bien plus variés en utilisant des petites briques qu'avec des gros blocs de marbre.

Expliqué comme ça, ça a du sens.
Il faut encore que le développeur connaisse l'application pour réutiliser/adapter les choses et pas re faire la roue. Et dans se sens plus c'est petit plus c'est facile de réutiliser.
Merci pour cette réponse constructive !

[copeau31]

Y a des gens qui ont le temps de faire du TDD en entreprise ?
Ça me parait utopique tout ça (je peux me tromper).

Perso je ne suis pas fan de cette méthode à la base donc ...

Oui.
Exceptionnellement, c'est arrivé.

Notamment une fois: Je me suis retrouvé à devoir faire un projet d'une centaine de jours. Mais sur ce projet personne n'est venu me demander des comptes, et pour une fois j'ai pu travailler "normalement" (les guillemets sont là parce que travailler normalement est malheureusement très anecdotique). Donc, loin des indicateurs d'avancement, et tant mieux parce que le nombre de lignes de codes écrites est resté à zéro presque jusqu'à la fin du projet
Et voilà, une fois le besoin bien clarifié avec le client (0 lignes de code), le design bien posé (0 lignes de code) les tests autos et sur banc bien écrits pour couvrir le besoin (et bien sûr, tous KO, base du tdd) (ok, là il y a des lignes de codes, mais 0 fonctionnalités implémentées)... Eh bien à ce moment là écrire le code a été pratiquement immédiat ! (et même si je m'attendais à de la facilité, je ne m'attendais pas à ce que ça soit à ce point là)
Résultat, pratiquement 60% de surprod. Je vous laisse faire les comptes.

Et je tiens à préciser que ce n'étais pas un projet spécialement adapté au tdd, juste un comme les autres.
Dernier point: le tdd n'est pas le seul facteur ici, l'autre étant d'avoir pu (et c'est rare aussi) clarifier le besoin suffisamment tôt dans le cycle de vie du projet.

[Cyrilange]

Grosse perte de temps. Je n'ai jamais et je ne ferais jamais ce genre de chose.

[Logan Mauzaize]

Grosse perte de temps. Je n'ai jamais et je ne ferais jamais ce genre de chose.

Un argument ?

L'approche de Uncle Bob (peut-être que ce n'est pas écrit dans ce billet mais déjà mentionné dans un autre) est de considérer le passage des tests autos comme une étape supplémentaire de la "compilation" (ou du build plus généralement).
Il utilise plusieurs groupes de tests du plus rapide (qui lance le plus souvent) au plus long (qu'il exécute moins souvent). Il définit également des ordres de grandeur ; à titre informatif, car il l'indique que la notion de "rapide" diffère suivant les personnes, les projets, les tâches, la complexité, etc.
Ces groupes sont exécutés suivant des cycles (surement à rapprocher avec les cycles mentionnés ici) allant de la sauvegarde du fichier (si possible lancer automatiquement), la fin de l'écriture d'un bloc, d'une macro (procédure, fonction), d'un module (classe, package, fichier source), etc.

Juste pour bien nuancer les propos les plus récents de Robert Martin avec les idées posées aux débuts de TDD (par lui-même notemment), il a avoué lui-même qu'il avait une vision différente de celle qu'il avait exposé voilà plus de dix ans ...

[boero-teyssier Greg]

De ce que je comprends (ce n'est pas le billet le plus limpide de Uncle Bob), on ne pète pas tout mais on prend de la hauteur pour se rendre compte de ce qu'il faut faire par la suite. Dans le milli-cycle, on s'aperçoit que l'implémentation telle qu'elle est ne va pas pouvoir faire passer tous les tests précédents + le nouveau test, donc on la rend plus générique. Dans le cycle primaire, on lève le nez pour voir qu'on est arrivé aux bornes d'un sous-système et on sait qu'il faut tracer une limite à cet endroit-là.

Oui mais il faut faire attention car comme agile la TDD et une méthode qu'il faut adapter à sa situation.

Ca, c'est le premier effet kiss cool : les tests sont le premier client qui va utiliser le code de production, donc on réfléchit plus à la conception d'un point de vue pragmatique/utilisateur de l'API. Mais il ne faut pas oublier les assertions à l'intérieur des tests qui vérifient le comportement du code de production, et serviront de filet de sécurité signalant des bugs pendant toute la suite du processus de développement.

Complètement d'accord avec toi la dessus

Moi je suis plutôt d'accord avec cette assertion, voici mon interprétation:

• Plus un test est spécifique, moins le bloc de code testé est étendu.
• Cela veut dire que les blocs testés sont plus petits et plus nombreux.
• Un bloc testé (et donc testable) est un bloc ayant un contrat clair, une entrée et une sortie bien définies et attendues.
• Ces blocs peuvent donc être réutilisés dans d'autre contextes.

À mon avis c'est ce qu'il faut retenir de ce billet et si nous les développeurs on respectée sa dans nos programme le temps de développement et de maintenance/évolution serais grandement diminuer.

Oui.
Exceptionnellement, c'est arrivé.

Notamment une fois: Je me suis retrouvé à devoir faire un projet d'une centaine de jours. Mais sur ce projet personne n'est venu me demander des comptes, et pour une fois j'ai pu travailler "normalement" (les guillemets sont là parce que travailler normalement est malheureusement très anecdotique). Donc, loin des indicateurs d'avancement, et tant mieux parce que le nombre de lignes de codes écrites est resté à zéro presque jusqu'à la fin du projet
Et voilà, une fois le besoin bien clarifié avec le client (0 lignes de code), le design bien posé (0 lignes de code) les tests autos et sur banc bien écrits pour couvrir le besoin (et bien sûr, tous KO, base du tdd) (ok, là il y a des lignes de codes, mais 0 fonctionnalités implémentées)... Eh bien à ce moment là écrire le code a été pratiquement immédiat ! (et même si je m'attendais à de la facilité, je ne m'attendais pas à ce que ça soit à ce point là)
Résultat, pratiquement 60% de surprod. Je vous laisse faire les comptes.

Et je tiens à préciser que ce n'étais pas un projet spécialement adapté au tdd, juste un comme les autres.
Dernier point: le tdd n'est pas le seul facteur ici, l'autre étant d'avoir pu (et c'est rare aussi) clarifier le besoin suffisamment tôt dans le cycle de vie du projet.

C’est aussi applicable sur d'autre projet si les membres de l’équipe joue leur rôle tu arrives a une expérience proche de celle que tu as eu.

Expliqué comme ça, ça a du sens.
Il faut encore que le développeur connaisse l'application pour réutiliser/adapter les choses et pas re faire la roue. Et dans se sens plus c'est petit plus c'est facile de réutiliser.
Merci pour cette réponse constructive !

Tout à fait mais la théorie ce n'est pas compliquée et facile à utiliser mais le plus dur viens de soi-même car il faut redéfinir notre façon de pansée
Qui et fonction de la plasticité neuronale de chacun

en conclusion :
la TDD n'est pas une science c'est une méthode elle doit être adapté au besoin de chacun et l'adaptation proposée n'est pas forcement la bonne solution
Donc il faut retournée au fondamentale de la méthode et d'en retirer ce qui est nécessaire

[Flodelarab]

si nous les développeurs on respectée sa dans nos programme le temps de développement et de maintenance/évolution serais grandement diminuer.

"(...) si, nous, les développeurs, respections ça dans nos programmes, le temps de développement et de maintenance/évolution serait grandement diminué."
(ni "on", ni "ont", ni "avions", ni "respectée")
Pitié, respecte l'orthographe et les gens qui lisent tes messages autant que les 4 règles que tu cites.


Un escalier roulant qui attrape le vêtement d'un enfant, mais qui ne s'arrête pas, finira par l'étouffer. Pourtant, il a exactement fait ce qu'on lui a demandé: il a tourné. Aucun bug. Cela fait sérieusement réfléchir sur la définition du bug.

Voilà pourquoi piloter le développement par trop de tests est néfaste. La recherche du zéro-bug est illusoire. Perte de temps donc d'argent.

[boero-teyssier Greg]

"(...) si, nous, les développeurs, respections ça dans nos programmes, le temps de développement et de maintenance/évolution serait grandement diminué."
(ni "on", ni "ont", ni "avions", ni "respectée")
Pitié, respecte l'orthographe et les gens qui lisent tes messages autant que les 4 règles que tu cites.


Un escalier roulant qui attrape le vêtement d'un enfant, mais qui ne s'arrête pas, finira par l'étouffer. Pourtant, il a exactement fait ce qu'on lui a demandé: il a tourné. Aucun bug. Cela fait sérieusement réfléchir sur la définition du bug.

Voilà pourquoi piloter le développement par trop de tests est néfaste. La recherche du zéro-bug est illusoire. Perte de temps donc d'argent.

Désolé pour cette faute honteuse mais j’ai écrit vite entre 2 compils et je n’ai pas eu le temps de me relire.

Tu fais l’erreur classique : tu fais une allégorie qui n’a rien à voir avec le sujet.

Mais pour rester sur ce que tu as dit, je pense plutôt :
quel test as-tu oublié pour que l’escalier roulant attrape le vêtement ?
En te placent du coté utilisateur de ton programme tu aurais dû penser à cette situation et mètres un test pour le vérifier (appelée test d’architecture)