+ Répondre à la discussion Actualité déjà publiée
Page 1 sur 2 12 DernièreDernière
Affichage des résultats 1 à 20 sur 25
  1. #1
    Rédacteur
    Avatar de thierryler
    Homme Profil pro
    Inscrit en
    octobre 2007
    Messages
    3 610
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : octobre 2007
    Messages : 3 610
    Points : 10 060
    Points
    10 060

    Par défaut 3T : les Tests en Trois Temps

    Bonjour à tous,

    Le TDD, la fameuse méthode de Développement Guidé par les Tests est devenue incontournable. Toutefois, elle n'est pas si simple à comprendre et à mettre en œuvre. Ce mini-article propose, comme version allégée du TDD, la "3T" qui, bien qu'incomplète, devrait suffire à la plupart des équipes.

    La suite de l'article : http://thierry-leriche-dessirier.dev...va/methode-3t/

    Bonne lecture.

    Th.

  2. #2
    Futur Membre du Club
    Homme Profil pro
    Étudiant
    Inscrit en
    août 2011
    Messages
    16
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Étudiant
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : août 2011
    Messages : 16
    Points : 17
    Points
    17

    Par défaut

    Bon tutoriel.

    mais je pense que l'outil qui permet de générer les tests depuis les spéc va être indispensable à tous le monde !

  3. #3
    Membre régulier
    Inscrit en
    juillet 2006
    Messages
    76
    Détails du profil
    Informations forums :
    Inscription : juillet 2006
    Messages : 76
    Points : 89
    Points
    89

    Par défaut

    C'est une approche que je ne partage pas.

    L'étape 1 génère des interfaces à tous va et crée l'anti pattern 1 class <-> 1 interface. Une interface n'a d’intérêt que si elle apporte une plus value (plusieurs implémentations, interface au frontière...)

    Il faut être pragmatique 2 et 3 peut très bien être 3 et 2 suivant le contexte.



    Je conseille la lecture de l'article suivant Breaking Away From The Unit Test Group Think de Cedric Beust.

  4. #4
    Rédacteur
    Avatar de thierryler
    Homme Profil pro
    Inscrit en
    octobre 2007
    Messages
    3 610
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : octobre 2007
    Messages : 3 610
    Points : 10 060
    Points
    10 060

    Par défaut

    Dans le cadre de la proposition "3T" il faut impérativement faire 1 puis 2 puis 3. Cette démarche permet de mécaniser l'écriture des tests. On écrit les tests avant le code. On dit d'abord ce qu'on veut tester.

    Quand à l'antipattern, je préfère ne pas m'exprimer sur la question.

  5. #5
    Membre régulier
    Inscrit en
    juillet 2006
    Messages
    76
    Détails du profil
    Informations forums :
    Inscription : juillet 2006
    Messages : 76
    Points : 89
    Points
    89

    Par défaut

    Citation Envoyé par thierryler Voir le message
    Dans le cadre de la proposition "3T" il faut impérativement faire 1 puis 2 puis 3. Cette démarche permet de mécaniser l'écriture des tests. On écrit les tests avant le code. On dit d'abord ce qu'on veut tester.

    Quand à l'antipattern, je préfère ne pas m'exprimer sur la question.
    Le terme anti pattern est trop fort. Disons que cela génère du code inutile sans valeur. Si tu as une opinion différente je suis preneur

    L'aspect mécanisations peut effectivement permettre à un débutant d’acquérir le réflexe test unitaire, mais avec l’expérience mon point de vu est que le coté dogmatique et figé 1->2->3 cède la place au pragmatisme

  6. #6
    Rédacteur
    Avatar de thierryler
    Homme Profil pro
    Inscrit en
    octobre 2007
    Messages
    3 610
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : octobre 2007
    Messages : 3 610
    Points : 10 060
    Points
    10 060

    Par défaut

    A mon sens, c'est un bon compromis pour les aspects que j'ai l'habitude de rencontrer. Je propose "3T" mais je n'impose rien.

    Edit : Comprend moi bien, je ne dis pas cela méchamment, mais il n'y a que 3 étapes dans "3T" alors si tu en enlèves une, ça devient "2T". Et si tu inverses 3 et 2, est ce encore du TDD ? J'ai longtemps réfléchi à une solution pour réussir à imposer une méthodologie de test, comme TDD, qui soit assez light pour ne pas susciter le rejet, mais assez stricte pour être mécanique, et puis qui guide/force le développeur vers des patterns qui fonctionnent.

    J'insiste : 1 puis 2 puis 3...

    Pourquoi cette démarche ? Tout simplement pour avoir une "normalisation" du processus, commune à toute l'équipe. Dès qu'un des développeurs commence à "être pragmatique" c'est la porte ouverte aux divergences.

    Le point important de "3T" est de "bannir" tout pragmatisme ou "prise de tête" en recopiant le cahier des charges pour avoir "exactement" ce qui est demandé. A noter que le développeur peut "demander" que les specs soient complétées. S'il veut être pragmatique (ou réfléchir) c'est lors de la validation/lecture du cahier des charges qu'il faut le faire.

    D'ailleurs (attention digression) la qualité d'un développeur ne vient pas de la maitrise pure de Java.

    En ce qui concerne les interfaces, je n'ai pas très envie d'entamer la discussion (ici) mais je pense que c'est un point "puissant" dans Java. Même s'il est vrai que c'est un peu lourd d'avoir une interface et une classe, ce n'est pas sans valeur. Pense que tu auras peut-être d'autres classes plus tard. En outre, l'interface décrit ton service. C'est ton interface que tu dois exposer et non l'implémentation.

  7. #7
    Membre éprouvé
    Inscrit en
    octobre 2007
    Messages
    210
    Détails du profil
    Informations forums :
    Inscription : octobre 2007
    Messages : 210
    Points : 448
    Points
    448

    Par défaut

    J'aurais appelé l'interface "Calculette" tout court. On a tous pris de mauvaises habitude à tout suffixer par "service", "manager" ... selon moi toutes les classes "gèrent" et "servent" ..

  8. #8
    Membre du Club
    Homme Profil pro
    Inscrit en
    mars 2011
    Messages
    31
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations forums :
    Inscription : mars 2011
    Messages : 31
    Points : 55
    Points
    55

    Par défaut

    Merci pour ce tutoriel.

    J'aurais une question - qui me fera sûrement passer pour l'idiot du village, mais bon, poser une question si on ne sait pas tout, c'est aussi une bonne démarche, :

    Est-ce qu'il y a une différence entre l'approche dirigée par les tests que tu décris et ce qu'on appelait la "programmation extrême" (XP) il y a quelques années ?

    Merci, et pardon si je déclenche l'hilarité générale...

  9. #9
    Rédacteur
    Avatar de thierryler
    Homme Profil pro
    Inscrit en
    octobre 2007
    Messages
    3 610
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : octobre 2007
    Messages : 3 610
    Points : 10 060
    Points
    10 060

    Par défaut

    Instinctivement j'aurais tendance à répondre que XP et TDD sont deux choses différentes. Toutefois je comprend pourquoi tu te poses cette question, qui n'est pas délirante du tout.

    Edit : Dans l'article sur "3T" je donne d'ailleurs un très bon lien sur les TDD.

  10. #10
    Membre éclairé
    Inscrit en
    mai 2007
    Messages
    241
    Détails du profil
    Informations forums :
    Inscription : mai 2007
    Messages : 241
    Points : 300
    Points
    300

    Par défaut

    Bonjour,
    j'ai du mal à voir exactement ce qui fait que le 3T n'est pas du TDD, mis à part qu'on ne s'impose pas de créer une simulation, et qu'on n'impose pas un cyle moins de 2minute pour le test, moins de 10 pour les cycles d'implémentation.

    En fait j'envisage d'utiliser le 3T pour expliquer le TDD, parce que c'est beaucoup plus simple à comprendre pour les décideurs qui ne codent pas.

  11. #11
    Expert Confirmé Sénior
    Avatar de _skip
    Homme Profil pro
    Développeur d'applications
    Inscrit en
    novembre 2005
    Messages
    2 732
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 31
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur d'applications
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : novembre 2005
    Messages : 2 732
    Points : 6 933
    Points
    6 933

    Par défaut

    Le TDD est en effet l'une des recommandations du "extreme programming" mais c'est juste un point parmi parmi de nombreux autres dans la méthodologie XP.
    Ce sont des notions différentes :

    XP est ensemble de règles et recommandations qui couvre la gestion de projet d'équipe alors que le TDD est une technique de développement.


    Pourquoi cette démarche ? Tout simplement pour avoir une "normalisation" du processus, commune à toute l'équipe. Dès qu'un des développeurs commence à "être pragmatique" c'est la porte ouverte aux divergences.

    Le point important de "3T" est de "bannir" tout pragmatisme ou "prise de tête" en recopiant le cahier des charges pour avoir "exactement" ce qui est demandé. A noter que le développeur peut "demander" que les specs soient complétées. S'il veut être pragmatique (ou réfléchir) c'est lors de la validation/lecture du cahier des charges qu'il faut le faire.
    C'est un point de vue, je pense que dans ton cas c'est la taille de l'équipe ou la présence de juniors qui force la normalisation du processus suivant les 3 étapes bien strictes. Il est totalement juste de dire qu'un code doit obéir aux spécifications et que l'approche 123 force la conformité.

    Mais là où je rejoins Nithril, c'est qu'en développement, dès que les problèmes à traiter ne sont pas triviaux, il arrive souvent qu'en cours d'implémentation on découvre que la solution de départ n'était pas optimale et nécessite une révision qui prend en compte de nouveaux éléments. Et dans ces cas, on peut être amené à devoir par la même occasion jeter ou retoucher toute la batterie de tests initiales ce qui provoque du travail dans le vide.

    C'est là que s'obliger a utiliser systématiquement le TDD peut être néfaste et qu'il peut être préférable de faire fonctionner, constater l'efficacité puis finalement blinder le tout avec des tests appropriés. Je pense que c'est ce qu'il a voulu dire.


    Même s'il est vrai que c'est un peu lourd d'avoir une interface et une classe, ce n'est pas sans valeur. Pense que tu auras peut-être d'autres classes plus tard. En outre, l'interface décrit ton service. C'est ton interface que tu dois exposer et non l'implémentation.
    J'avais l'intention de créer un débat sur les dangers de l'overengineering et la surabstraction...

  12. #12
    Rédacteur
    Avatar de thierryler
    Homme Profil pro
    Inscrit en
    octobre 2007
    Messages
    3 610
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : octobre 2007
    Messages : 3 610
    Points : 10 060
    Points
    10 060

    Par défaut

    j'ai du mal à voir exactement ce qui fait que le 3T n'est pas du TDD
    Tu peux voir "3T" comme une approche guidée vers un TDD simplifié.


    En fait j'envisage d'utiliser le 3T pour expliquer le TDD, parce que c'est beaucoup plus simple à comprendre pour les décideurs qui ne codent pas.
    Et je t'en remercie par avance ;-)


    C'est un point de vue, je pense que dans ton cas c'est la taille de l'équipe ou la présence de juniors qui force la normalisation du processus suivant les 3 étapes bien strictes.
    Les problèmes dont tu parles et que j'ai pu constater ne venait pas, en général, exclusivement des juniors. D'ailleurs les séniors utilisent souvent le mot magique "pragmatique" pour dire "j'ai pas envie de suivre la règle et je préfère faire à ma façon".

    Le principe de "3T" est de fixer un cadre simple qu'il suffit de suivre pour être à peu près certain de réussir. Cela a évidement un cout.

    Et dans ces cas, on peut être amené à devoir par la même occasion jeter ou retoucher toute la batterie de tests initiales ce qui provoque du travail dans le vide.
    Ce n'est justement pas du travail dans le vide, bien au contraire. J'irais même jusqu'à dire que c'est là que ça se passe.


    C'est là que s'obliger a utiliser systématiquement le TDD peut être néfaste et qu'il peut être préférable de faire fonctionner, constater l'efficacité puis finalement blinder le tout avec des tests appropriés. Je pense que c'est ce qu'il a voulu dire.
    A mon sens, mais ça n'engage que moi, faire les tests après le dev, déjà ce n'est pas du TDD, et ensuite tu perds 50% de la puissance des tests. Tester un truc qui marche, c'est utile pour la non régression.

    Faut aussi penser à un truc, c'est que tes tests sont aussi là pour prouver au client que le logiciel fonctionne. L'idéal serait même que ce soit le client qui écrive les tests. Justement dans "3T" c'est un peu le cas puisqu'on recopie carrément le cahier des charges, sans en changer le sens. C'est comme si le client avait lui-même rédigé les tests.

    J'avais l'intention de créer un débat sur les dangers de l'overengineering et la surabstraction...
    Pour moi, et là encore ça n'engage que moi, écrire une interface pour décrire un service, ça ne peut en aucun cas être une mauvaise pratique.

    D'ailleurs, quand on utilise certains frameworks, comme Seam, on peut (la doc le recommande) n'avoir que les dépendances vers les API en dev (ie les interfaces dans Eclipse) et compléter avec les Impl pour la génération.

  13. #13
    Rédacteur
    Avatar de thierryler
    Homme Profil pro
    Inscrit en
    octobre 2007
    Messages
    3 610
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : octobre 2007
    Messages : 3 610
    Points : 10 060
    Points
    10 060

    Par défaut

    Ajout, en FAQ, de la définition de "tâche terminée" dans le cadre de 3T.

    Peut-on parler de "3T Terminée", soit de "3T bis" ? LOL

  14. #14
    Rédacteur
    Avatar de thierryler
    Homme Profil pro
    Inscrit en
    octobre 2007
    Messages
    3 610
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : octobre 2007
    Messages : 3 610
    Points : 10 060
    Points
    10 060

  15. #15
    Membre actif
    Homme Profil pro
    Développeur Web
    Inscrit en
    mai 2011
    Messages
    63
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Madagascar

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : mai 2011
    Messages : 63
    Points : 191
    Points
    191

    Par défaut Super tuto

    Les tests en trois temps sont très intéressantes et je cherche un moyen de les implémenter dans mon travail. Bien que je développe en php principalement, la méthode me semble tellement efficace et facile.

    Les articles m'ont fait prendre un peu de recule par rapport au codage pour réfléchir en terme de qualité, d’efficacité et de professionnalisme.

    Aucun article ne m'a jamais autant inspiré. La plupart des méthodes sont soit trop lourdes a mettre en œuvre, soit du domaine du code uniquement. Je me suis rapidement intéressé a scrum aussi et l'intégration continue.

    Je me demande encore pourquoi tant de méthodes ont été développés principalement sur la technologie java et pas des autres langages. Je me suis, d’ailleurs, rendu compte rapidement que la plupart des outils tournent autour de java (Jenkins pour l'intégration continue par exemple).

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

    Informations professionnelles :
    Activité : Architecte technique
    Secteur : Transports

    Informations forums :
    Inscription : août 2005
    Messages : 2 192
    Points : 4 896
    Points
    4 896

    Par défaut

    Ces méthodes sont nées en même temps que l'essor de Java, et aujourd'hui Java représente une belle part de marché.
    D'ailleurs ces méthodes nécessitent pas mal d'outillage (Test unitaire, Mock, Couverture de code, Intégration Continue, Bug tracker, Analyse statique, etc.) Et la plupart de ces outils ont d'abord été créé pour Java.

    Et parfois certains outils nécessitent des langages un peu évolué (Invocation dynamique, Introspection, etc.)


    Concernant Jenkins/Hudson/Continuum/CruiseControl, ils peuvent parfaitement être utilisés pour d'autres types de projet que ceux en Java.
    Java : Forum - FAQ - Java SE 8 API - Java EE 7 API
    Articles sur Ceylon : Présentation et installation - Concepts de base - Typage

    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

  17. #17
    Rédacteur
    Avatar de thierryler
    Homme Profil pro
    Inscrit en
    octobre 2007
    Messages
    3 610
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : octobre 2007
    Messages : 3 610
    Points : 10 060
    Points
    10 060

    Par défaut

    Bonjour,

    Aucun article ne m'a jamais autant inspiré.
    Merci beaucoup. Je prend ça comme un compliment. Ca fait plaisir d'avoir des fans.

    Même si PHP est un peu moins outillé que Java, ça l'est largement assez pour faire du 3T. Il faudrait demander à un spécialiste de PHP de nous indiquer les framework à utiliser.
    Thierry Leriche-Dessirier
    Consultant Java JEE Web Agile freelance
    Rédacteur pour Developpez
    Professeur de Génie Logiciel à l'ESIEA

    Site : http://www.icauda.com / Linked'in : http://www.linkedin.com/in/thierryler / Twitter : @ThierryLeriche
    Test DISC gratuit : http://www.profil4.com

  18. #18
    Rédacteur
    Avatar de thierryler
    Homme Profil pro
    Inscrit en
    octobre 2007
    Messages
    3 610
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : octobre 2007
    Messages : 3 610
    Points : 10 060
    Points
    10 060

    Par défaut

    Je répond après plusieurs mois à propos de ça :

    L'étape 1 génère des interfaces à tous va et crée l'anti pattern 1 class <-> 1 interface. Une interface n'a d’intérêt que si elle apporte une plus value (plusieurs implémentations, interface au frontière...)
    En ce qui me concerne, je pense qu'on ne perd jamais à faire une I et une C. Et c'est ce que je recommande dans le cadre de 3T. Toutefois, après avoir pesé le pour et le contre (c'est ce qui m'a pris aussi longtemps), je pense qu'on peut se contenter de faire une classe seulement (donc pas de I). Mais dans ce cas, lors du premier temps, il faut faire des méthodes vides, qui renvoient de UnsuportedOperationException par exemple. Néanmoins, je voudrais insister sur le fait que je ne cautionne pas cette pratique.
    Thierry Leriche-Dessirier
    Consultant Java JEE Web Agile freelance
    Rédacteur pour Developpez
    Professeur de Génie Logiciel à l'ESIEA

    Site : http://www.icauda.com / Linked'in : http://www.linkedin.com/in/thierryler / Twitter : @ThierryLeriche
    Test DISC gratuit : http://www.profil4.com

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

    Informations professionnelles :
    Activité : Architecte technique
    Secteur : Transports

    Informations forums :
    Inscription : août 2005
    Messages : 2 192
    Points : 4 896
    Points
    4 896

    Par défaut

    Disons que 3T étant une méthode "rapide", c'est dommage de perdre un peu de temps avec ça. Même si avec un IDE moderne ça prend pas plus de quelques secondes à générer l'implémentation.

    Ensuite pour avoir quelques projets où cette pratique a été appliquée, ça devient très lourd à la maintenance. Et sans un IDE moderne c'est un calvaire de naviguer entre les classes et les implémentations.
    Ca alourdie considérablement la code sans rien lui apporter.

    Je préfère la méthode de refactorisation si j'ai besoin de généraliser ce qui a commencé par être spécifique, plutôt que commencer par généraliser quelque chose qui a uniquement pour but d'être spécifique.
    D'ailleurs il me semble que c'est la préconisation d'XP en matière de "pragmatisme" : ne fait que ce qui est utile.
    Il est intéressant de noter que c'est également un élément clé des UP.
    Java : Forum - FAQ - Java SE 8 API - Java EE 7 API
    Articles sur Ceylon : Présentation et installation - Concepts de base - Typage

    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

  20. #20
    Rédacteur
    Avatar de thierryler
    Homme Profil pro
    Inscrit en
    octobre 2007
    Messages
    3 610
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : octobre 2007
    Messages : 3 610
    Points : 10 060
    Points
    10 060

    Par défaut

    Je vous encourage à lire également, si ce n'est pas déjà fait, les deux articles suivants :

    * Les Tests en Trois Temps (3T) en pratique
    "3T" est une version simplifiée des incontournables TDD (Test Driven Development), une méthode dans laquelle on commence par écrire des tests pour aider (guider) le développement des fonctionnalités. Ce second article sur le sujet propose une illustration de "3T" en action sous forme d'un miniroman.
    http://thierry-leriche-dessirier.dev...t-en-pratique/

    * 3T en pratique, application au calcul de la suite de Fibonnaci, en 5 minutes
    Ce petit tutoriel montre comment mettre en œuvre 3T (Tests en Trois Temps), pour développer une fonctionnalité simple (la suite de Fibonnaci dans l'exemple) en s'aidant des tests, le tout en quelques minutes.
    http://thierry-leriche-dessirier.dev...acci-3t-5-min/

    Par ailleurs, je voudrais préciser que je suis preneur de toutes les remarques, positives ou négatives, pour faire évoluer la "méthode" vers le meilleur compromis.
    Thierry Leriche-Dessirier
    Consultant Java JEE Web Agile freelance
    Rédacteur pour Developpez
    Professeur de Génie Logiciel à l'ESIEA

    Site : http://www.icauda.com / Linked'in : http://www.linkedin.com/in/thierryler / Twitter : @ThierryLeriche
    Test DISC gratuit : http://www.profil4.com

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •