IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

ALM Discussion :

Les bonnes habitudes du développement piloté par les tests


Sujet :

ALM

  1. #1
    Expert éminent sénior

    Homme Profil pro
    Développeur informatique
    Inscrit en
    septembre 2014
    Messages
    194
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Algérie

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : septembre 2014
    Messages : 194
    Points : 12 283
    Points
    12 283
    Par défaut Les bonnes habitudes du développement piloté par les tests
    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 ?

  2. #2
    Membre confirmé

    Homme Profil pro
    Développeur Java
    Inscrit en
    février 2007
    Messages
    179
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur Java
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : février 2007
    Messages : 179
    Points : 649
    Points
    649
    Par défaut
    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]
    L'expérience est une lanterne que l'on porte sur le dos et qui n'eclaire jamais que le chemin parcouru.

    La nature fait les choses sans se presser, et pourtant tout est accompli.

  3. #3
    Membre averti
    Homme Profil pro
    Inscrit en
    avril 2009
    Messages
    208
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : avril 2009
    Messages : 208
    Points : 393
    Points
    393
    Par défaut
    Citation Envoyé par Angelsafrania Voir le message
    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.

  4. #4
    Nouveau membre du Club
    Homme Profil pro
    Développeur informatique
    Inscrit en
    août 2014
    Messages
    12
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Isère (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : août 2014
    Messages : 12
    Points : 29
    Points
    29
    Par défaut
    Citation Envoyé par Arnaud13 Voir le message
    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.

  5. #5
    Membre averti
    Homme Profil pro
    Inscrit en
    avril 2009
    Messages
    208
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : avril 2009
    Messages : 208
    Points : 393
    Points
    393
    Par défaut
    Citation Envoyé par boero-teyssier Greg Voir le message
    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".

  6. #6
    Membre habitué
    Inscrit en
    juillet 2007
    Messages
    65
    Détails du profil
    Informations forums :
    Inscription : juillet 2007
    Messages : 65
    Points : 127
    Points
    127
    Par défaut
    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 ...

  7. #7
    Nouveau membre du Club
    Homme Profil pro
    Développeur informatique
    Inscrit en
    août 2014
    Messages
    12
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Isère (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : août 2014
    Messages : 12
    Points : 29
    Points
    29
    Par défaut
    Citation Envoyé par Arnaud13 Voir le message
    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


    Citation Envoyé par Gulien Voir le message
    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

  8. #8
    Invité
    Invité(e)
    Par défaut
    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!

  9. #9
    Membre éprouvé
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    janvier 2007
    Messages
    697
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : France, Calvados (Basse Normandie)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : janvier 2007
    Messages : 697
    Points : 1 238
    Points
    1 238
    Par défaut
    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).

    Citation Envoyé par Angelsafrania Voir le message
    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

    Citation Envoyé par Angelsafrania Voir le message
    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

    Citation Envoyé par Arnaud13 Voir le message
    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.

    Citation Envoyé par Arnaud13 Voir le message
    , 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

    Citation Envoyé par boero-teyssier Greg Voir le message
    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 :
    Citation Envoyé par boero-teyssier Greg Voir le 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) :
    Citation Envoyé par boero-teyssier Greg Voir le message
    en TDD on dit que l’architecture émerge.
    Citation Envoyé par Gulien Voir le message
    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...).

    Citation Envoyé par galerien69 Voir le message
    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]

  10. #10
    Débutant
    Profil pro
    Inscrit en
    mai 2006
    Messages
    688
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mai 2006
    Messages : 688
    Points : 171
    Points
    171
    Par défaut
    vaste blague ces tests unitaires, quelle perte de temps

  11. #11
    Membre émérite
    Inscrit en
    janvier 2011
    Messages
    805
    Détails du profil
    Informations personnelles :
    Localisation : Autre

    Informations forums :
    Inscription : janvier 2011
    Messages : 805
    Points : 2 931
    Points
    2 931
    Par défaut
    Citation Envoyé par Angelsafrania Voir le message
    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à.

  12. #12
    Membre émérite
    Inscrit en
    janvier 2011
    Messages
    805
    Détails du profil
    Informations personnelles :
    Localisation : Autre

    Informations forums :
    Inscription : janvier 2011
    Messages : 805
    Points : 2 931
    Points
    2 931
    Par défaut
    Citation Envoyé par galerien69 Voir le message
    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.

  13. #13
    Membre habitué
    Profil pro
    Inscrit en
    octobre 2009
    Messages
    73
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : octobre 2009
    Messages : 73
    Points : 170
    Points
    170
    Par défaut
    plus les tests sont spécifiques, plus le code devient générique.
    Citation Envoyé par Angelsafrania Voir le message
    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.

  14. #14
    Membre confirmé

    Homme Profil pro
    Développeur Java
    Inscrit en
    février 2007
    Messages
    179
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur Java
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : février 2007
    Messages : 179
    Points : 649
    Points
    649
    Par défaut
    Citation Envoyé par Mens Pervincet Voir le message
    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 !
    L'expérience est une lanterne que l'on porte sur le dos et qui n'eclaire jamais que le chemin parcouru.

    La nature fait les choses sans se presser, et pourtant tout est accompli.

  15. #15
    Membre du Club
    Profil pro
    Inscrit en
    janvier 2006
    Messages
    66
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : janvier 2006
    Messages : 66
    Points : 42
    Points
    42
    Par défaut
    Citation Envoyé par Gulien Voir le message
    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.

  16. #16
    Membre averti
    Avatar de Cyrilange
    Profil pro
    Inscrit en
    février 2004
    Messages
    268
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : février 2004
    Messages : 268
    Points : 342
    Points
    342
    Par défaut
    Grosse perte de temps. Je n'ai jamais et je ne ferais jamais ce genre de chose.

  17. #17
    Rédacteur/Modérateur
    Avatar de Logan Mauzaize
    Homme Profil pro
    Architecte technique
    Inscrit en
    août 2005
    Messages
    2 894
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Architecte technique
    Secteur : Transports

    Informations forums :
    Inscription : août 2005
    Messages : 2 894
    Points : 7 195
    Points
    7 195
    Par défaut
    Citation Envoyé par Cyrilange Voir le message
    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 ...
    Java : Cours et tutoriels - FAQ - Java SE 8 API - Programmation concurrente
    Ceylon : Installation - Concepts de base - Typage - Appels et arguments

    ECM = Exemple(reproduit le problème) Complet (code compilable) Minimal (ne postez pas votre application !)
    Une solution vous convient ? N'oubliez pas le tag
    Signature par pitipoisson

  18. #18
    Nouveau membre du Club
    Homme Profil pro
    Développeur informatique
    Inscrit en
    août 2014
    Messages
    12
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Isère (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : août 2014
    Messages : 12
    Points : 29
    Points
    29
    Par défaut
    Citation Envoyé par Luckyluke34 Voir le message
    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.

    Citation Envoyé par Luckyluke34 Voir le message
    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

    Citation Envoyé par Mens Pervincet Voir le message
    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.


    Citation Envoyé par copeau31 Voir le message
    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.

    Citation Envoyé par Angelsafrania Voir le message
    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

  19. #19
    Expert éminent sénior Avatar de Flodelarab
    Homme Profil pro
    Inscrit en
    septembre 2005
    Messages
    4 807
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Charente (Poitou Charente)

    Informations forums :
    Inscription : septembre 2005
    Messages : 4 807
    Points : 12 078
    Points
    12 078
    Par défaut
    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.
    Cette réponse vous apporte quelque chose ? Cliquez sur en bas à droite du message.

  20. #20
    Nouveau membre du Club
    Homme Profil pro
    Développeur informatique
    Inscrit en
    août 2014
    Messages
    12
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Isère (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : août 2014
    Messages : 12
    Points : 29
    Points
    29
    Par défaut
    Citation Envoyé par Flodelarab Voir le message
    "(...) 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)

Discussions similaires

  1. [PHPUnit] Développement piloté par les tests
    Par Invité dans le forum Bibliothèques et frameworks
    Réponses: 2
    Dernier message: 12/11/2013, 13h19
  2. Réponses: 9
    Dernier message: 26/01/2012, 10h33
  3. développement piloté par les tests pour un jeu vidéo
    Par Mindiell dans le forum Méthodes Agiles
    Réponses: 1
    Dernier message: 06/08/2009, 10h28
  4. Développement piloté par les tests avec PHPUnit
    Par Invité dans le forum Bibliothèques et frameworks
    Réponses: 0
    Dernier message: 18/11/2008, 19h53

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo