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

  1. #1
    Expert éminent sénior

    Homme Profil pro
    Étudiant
    Inscrit en
    août 2011
    Messages
    283
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Algérie

    Informations professionnelles :
    Activité : Étudiant
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : août 2011
    Messages : 283
    Points : 18 075
    Points
    18 075
    Par défaut Le TDD nécessite plus de qualifications techniques et de discipline de la part des développeurs pour son succè
    Le TDD nécessite plus de qualifications techniques et de discipline de la part des développeurs pour son succès
    selon un adepte d'agile

    Le développement piloté par le test est-il réellement mort ? La réponse est un non catégorique, pour Scott Ambler consultant pour le compte d’une entreprise spécialisée dans l’adoption des stratégies et du développement agile.

    Pour le consultant senior, le développement piloté par le test (TDD) a encore de beaux jours devant lui, mais il demande plus de qualifications techniques, d’expérience et de discipline, aussi il semblerait qu’il soit l’une des pratiques adoptées par les adeptes du développement agile.

    Ces constats se fondent sur les résultats d’une étude menée par Ambler sur 247 équipes ayant adopté le TDD, ces mêmes résultats révèlent que 40% des sondés ont une expérience moyenne de 16 ans dans le développement logiciel.

    Mais l’étude ne s’arrête pas en si bon chemin, elle se concentre sur les autres pratiques et méthodes qui ont lieu en plus du TDD, mais aussi sur d’autres aspects comme sa capacité à exprimer les exigences et les besoins ou l’efficacité et la nature des tests effectués dans le cadre du TDD.

    En effet, le TDD peut être utilisé pour exprimer des exigences de manière détaillée, à la volée au fur et à mesure de l’avancement du projet, cette pratique est appelée ATDD (Acceptante Test-Driven Development ) ou BDD (Behavior Driven Developement).

    Bien qu’offrant plusieurs avantages, l’ATDD ne permet pas d’exprimer les exigences dans la plupart des cas, ce qui pousse les développeurs à suppléer l’ATDD de différentes manières : en dessinant des croquis sur des tableaux ou sur papier (76% des cas), en exprimant les exigences de manière écrite via des logiciels de traitement de texte (54%) ou sur papier (46%) ou encore en recourant à des diagrammes et à des outils de modélisation (18%).

    L’étude se focalise aussi sur un aspect très important du TDD : les tests logiciels, ainsi dans 62% des cas les testeurs sont membres de l’équipe de développement, alors que dans 33% des cas l’équipe de test travaille en parallèle à l’équipe de développement.

    Plus encore, l’étude met l’accent sur les lacunes des tests de confirmation qui tendent à vérifier uniquement les exigences préalablement exprimées, les équipes expérimentées pallient ses lacunes en effectuant des tests exploratoires qui permettent généralement de découvrir des vulnérabilités ou d’identifier des exigences non exprimées par les parties prenantes, sans oublier les tests d’intégration qui vérifient et consolident l’intégration du logiciel dans des environnements complexes.

    Au final, même si le TDD n’est pas aussi commun que ce que souhaitent ces protagonistes, il apparaît clairement que le TDD est loin d’avoir dit son dernier mot et que face à ses lacunes, les développeurs pallient en le suppléant par de nombreuses pratiques de développement logiciel.

    Source : Objective View magazine - The Life and Times of TDD

    Et vous ?
    Qu’en pensez-vous ?

  2. #2
    Expert éminent

    Avatar de deusyss
    Homme Profil pro
    Expert Python
    Inscrit en
    mars 2010
    Messages
    1 659
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations professionnelles :
    Activité : Expert Python
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : mars 2010
    Messages : 1 659
    Points : 8 433
    Points
    8 433
    Par défaut
    Citation Envoyé par Arsene Newman Voir le message
    Et vous ?
    Qu’en pensez-vous ?
    J'en pense que les équipes pensant pouvoir se passer de test se trompe totalement. Comment peux t on espérer créer du code de qualité sans un minimum de test afin de vérifier que ce qu'on a écrit est fonctionnel et répond aux attentes?

    C'est le genre de question que l'on ne devrait meme pas se poser. Quel que soit le niveau de test, il doit y en avoir un minimum. Sinon, on se retrouve avec des logiciels totalement buggé, comme on en voit passer de temps en temps.

    Dommage que l'étude n'effectue pas un comparatif avec les équipes n'effectuant aucuns tests, car je pense que les indices de qualité de code résultant auraient été significatifs.

    Après sur la question se rapportant au fait de disposer de dev effectuant les tests, ou d'avoir une equipe de test dédié, on trouvera toujours des avis partagé. Certes, si les devs écrivent eux même leurs tests, ils peuvent être influencés par le code écrit, d'ou l'intérêt d'une equipe dédiée test. Cependant, s'il prenne le temps d'écrire leur test avant, en se basant sur les documentations techniques et fonctionnelles, aucun risque d'influence; et donc l'utilité d'une equipe dédiée test est remise en question. De même, si les devs s'occupent eux-même des tests, ils ont moins de temps pour développer.

    Bref sur ce dernier point, il s'agit avant d'ou de compromis en fonction des contraintes client.

    Quoiqu'il en soit cette étude met en évidence l'utilité et l'importance des tests pour avoir un développement de qualité.
    "La connaissance appartient à tout le monde" (Film Antitrust)

    Tout le nécessaire pour Python:
    *News/Accueil *Cours/tutoriels *FAQ
    *Forums *Outils dédiés *Mon espace personnel avec mes Articles, Cours et Tutoriels

  3. #3
    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 : 647
    Points
    647
    Par défaut
    Les tests sont important, tout le monde en convient (même si certain dirons que tester c'est douter).
    Moins les tests sont fait par les utilisateurs mieux c'est (pour l'image en cas de dysfonctionnement).
    Après comment faire les tests.
    Comme chez une de mes anciennes mission (FT), tout en papier avec des fichiers Word ou Excel (même si on dirait qu'ils commencent à bouger la dessus). Ça marche mal, on ne repasse jamais les anciens tests parce que trop long. Et si on doit tout repasser ça coûte chère donc le client ne veut pas.
    Ou comme actuellement ou on fait du test unitaire et intégration automatisé. Dans l'équipe certain le font en TDD et d'autre pas. Ça marche pas mal, le seul problème c'est que c'est des applications en agile, donc y'a beaucoup de chose qui change. Les tests sont souvent à réécrire ou adapter.

    Ce que je préfère c'est quand même des tests automatisés en TDD (généralement y'a une meilleur couverture et moins de tests inutiles).

    Après faire que des tests unitaires ou que des tests d'intégrations.
    J'ai des collègues qui préfère faire que des tests d'intégrations. Parce qu'ils pensent que seul le résultat final est intéressant et plus les test ressemble à ce que va faire l'utilisateur mieux c'est. Pour moi c'est un mix de tous les tests qui faut faire. Les tests aux limites plus faire au niveau unitaire, et les tests normaux plus niveau intégration, mais bon le mieux c'est de faire la total ^^


    [EDIT]
    Le TDD je connais, j'en fait.
    Le TDD ca reste des tests, pour faire du TDD il faut déjà faire des tests.
    Avec du vrai cycle en V normalement on fait du TDD vu que les tests sont écrits avant la phase de développement (pour les tests de plus haut niveau).
    [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.

  4. #4
    Membre chevronné
    Homme Profil pro
    Développeur informatique
    Inscrit en
    juillet 2007
    Messages
    838
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : juillet 2007
    Messages : 838
    Points : 1 804
    Points
    1 804
    Par défaut
    Mais tu n'a jamais travaillé dans une entreprise informatique? Le test est toujours présent quelques soit la méthode. Le TDD est simplement une méthode de développement qui le met en avant et en principal fil directeur.

    J'en pense que c'est une solution efficace qui certes demande des compétences mais que ce n'est pas la seul possible tout dépends du niveau de qualité exigé, de la taille du projet, des délais impartis, des financements et enfin pour une part importante de l'habitude des développeurs (qui est un mixte de leurs compétences/préférences).
    Tout ce que j'écris est libre de droits (Licence CC0) et je vous incite à faire de même.

  5. #5
    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 : 647
    Points
    647
    Par défaut
    Citation Envoyé par abriotde Voir le message
    Mais tu n'a jamais travaillé dans une entreprise informatique? Le test est toujours présent quelques soit la méthode.
    Je suis désolé mais dans certaine entreprise il n'y a pas de test, en SSII y'en a toujours un peu. Mais les clients final qui font leur propre logiciel ça arrive que se soit l'utilisateur qui test en prod.
    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.

  6. #6
    Membre émérite

    Profil pro
    Inscrit en
    décembre 2003
    Messages
    3 995
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : décembre 2003
    Messages : 3 995
    Points : 2 288
    Points
    2 288
    Par défaut
    Citation Envoyé par deusyss Voir le message
    J'en pense que les équipes pensant pouvoir se passer de test se trompe totalement. Comment peux t on espérer créer du code de qualité sans un minimum de test afin de vérifier que ce qu'on a écrit est fonctionnel et répond aux attentes?

    C'est le genre de question que l'on ne devrait meme pas se poser. Quel que soit le niveau de test, il doit y en avoir un minimum. Sinon, on se retrouve avec des logiciels totalement buggé, comme on en voit passer de temps en temps.

    Dommage que l'étude n'effectue pas un comparatif avec les équipes n'effectuant aucuns tests, car je pense que les indices de qualité de code résultant auraient été significatifs.

    Après sur la question se rapportant au fait de disposer de dev effectuant les tests, ou d'avoir une equipe de test dédié, on trouvera toujours des avis partagé. Certes, si les devs écrivent eux même leurs tests, ils peuvent être influencés par le code écrit, d'ou l'intérêt d'une equipe dédiée test. Cependant, s'il prenne le temps d'écrire leur test avant, en se basant sur les documentations techniques et fonctionnelles, aucun risque d'influence; et donc l'utilité d'une equipe dédiée test est remise en question. De même, si les devs s'occupent eux-même des tests, ils ont moins de temps pour développer.

    Bref sur ce dernier point, il s'agit avant d'ou de compromis en fonction des contraintes client.

    Quoiqu'il en soit cette étude met en évidence l'utilité et l'importance des tests pour avoir un développement de qualité.
    Ce n'est pas de ça qu'il s'agit. TDD est une méthodologie qui propose d'écrire les tests avant d'écrire le code, c'est à dire d'écrire des tests qui couvrent toutes les fonctionnalités, de manière à ne plus avoir qu'à écrire du code capable à satisfaire ces tests pour avoir fini son travail. C'est une approche différente de l'approche traditionnelle, où on écrit les tests après avoir codé.

  7. #7
    Invité
    Invité(e)
    Par défaut
    Citation Envoyé par Angelsafrania Voir le message
    Ça marche pas mal, le seul problème c'est que c'est des applications en agile, donc y'a beaucoup de chose qui change. Les tests sont souvent à réécrire ou adapter.
    L'objectif de l'agile n'est pas le changement permanent mais la réactivité et l'adaptabilité aux demandes du client, cela dit je ne vois ce qui surprend à tester de nouveau quand les spécs changent.

    Citation Envoyé par Angelsafrania
    Après faire que des tests unitaires ou que des tests d'intégrations.
    Les deux vu qu'ils ne font pas la même chose.

    Citation Envoyé par Arsene Newman Voir le message
    Plus encore, l’étude met l’accent sur les lacunes des tests de confirmation qui tendent à vérifier uniquement les exigences préalablement exprimées, les équipes expérimentées pallient ses lacunes en effectuant des tests exploratoires qui permettent généralement de découvrir des vulnérabilités ou d’identifier des exigences non exprimées par les parties prenantes, sans oublier les tests d’intégration qui vérifient et consolident l’intégration du logiciel dans des environnements complexes.
    Lacunes? Enfin la base des tests c'est de valider le cahier des charges plus les "problèmes" d'implémentations.
    Faut peut-être pas voir dans le TDD la fin de tous les problèmes du développement logiciel.
    Dernière modification par Invité ; 15/09/2014 à 11h58.

  8. #8
    Membre extrêmement actif
    Avatar de benjani13
    Homme Profil pro
    Consultant en sécurité
    Inscrit en
    février 2010
    Messages
    615
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Ain (Rhône Alpes)

    Informations professionnelles :
    Activité : Consultant en sécurité

    Informations forums :
    Inscription : février 2010
    Messages : 615
    Points : 2 822
    Points
    2 822
    Par défaut
    Citation Envoyé par abriotde Voir le message
    Mais tu n'a jamais travaillé dans une entreprise informatique? Le test est toujours présent quelques soit la méthode. Le TDD est simplement une méthode de développement qui le met en avant et en principal fil directeur.
    Eu... j'ai bossé un an dans une SSI (très grosse, internationale), on ne m'a pas appris a faire les tests sur la plateforme utilisé (un ERP), on ne m'a pas demandé de faire des tests (en gros le chef passait pour dire "Ça marche? ok on livre au client", sans rien vérifier), et une fois livré j'ai jamais eu de nouvelles.

    Donc ça existe...

  9. #9
    Expert éminent sénior
    Avatar de Marco46
    Homme Profil pro
    Développeur informatique
    Inscrit en
    août 2005
    Messages
    4 413
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : août 2005
    Messages : 4 413
    Points : 19 285
    Points
    19 285
    Par défaut
    Citation Envoyé par valkirys Voir le message
    Lacunes? Enfin la base des tests c'est de valider le cahier des charges plus les "problèmes" d'implémentations.
    Faut peut-être pas voir dans le TDD la fin de tous les problèmes du développement logiciel.
    De quels tests tu parles ?

    La base des tests automatisés (TU TI e2e) c'est de donner de la visibilité sur la qualité du code après une modification.

    Le TDD est peut être une pratique extrême, mais l'absence de tests automatisés à notre époque c'est clairement de l'amateurisme.
    Un problème avec Git ? Essayez la FAQ, sinon posez votre question sur le forum.



    "Toute personne croyant qu'une croissance exponentielle peut durer indéfiniment dans un monde fini est soit un fou, soit un économiste."
    Kenneth E. Boulding

    "Les richesses naturelles sont inépuisables, car, sans cela, nous ne les obtiendrions pas gratuitement. Ne pouvant être ni multipliées ni épuisées, elles ne sont pas l’objet des sciences économiques."
    Jean-Baptiste Say, Traité d'économie politique, 1803.

    "/home/earth is 102% full ... please delete anyone you can."
    Inconnu

  10. #10
    Expert éminent sénior
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    septembre 2012
    Messages
    2 982
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Finistère (Bretagne)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : septembre 2012
    Messages : 2 982
    Points : 15 922
    Points
    15 922
    Par défaut
    Citation Envoyé par Arsene Newman Voir le message
    ces mêmes résultats révèlent que 40% des sondés ont une expérience moyenne de 16 ans dans le développement logiciel
    (quasi) impossible en France. Quand tu as plus de 15 ans de dev, c'est soit que tu es dans le plus profond des placards et que tu attends sagement une hypothétique retraite, soit que tu es indépendant.

  11. #11
    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 : 647
    Points
    647
    Par défaut
    Citation Envoyé par valkirys Voir le message
    L'objectif de l'agile n'est pas le changement permanent mais la réactivité et l'adaptabilité aux demandes du client, cela dit je ne vois ce qui surprend à tester de nouveau quand les spécs changent.
    Je suis actuellement en Agile, je vois ce que ça donne. J'aime bien le principe de fonctionnement, j'ai jamais dit qu'on changeait des choses pour les changer.
    Mais vu que c'est plus du refacto régulier (ce qui est normal) y'a souvent les tests qui ne changent pas dans ce qu'ils font sont à changer. Après savoir écrire des tests qui peuvent évolué ca se fait pas facilement (transparent) encore moins en TDD.
    Et dans ce cas là je comprend que l'expérience soit utile !
    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.

  12. #12
    Expert confirmé Avatar de DonQuiche
    Inscrit en
    septembre 2010
    Messages
    2 741
    Détails du profil
    Informations forums :
    Inscription : septembre 2010
    Messages : 2 741
    Points : 5 459
    Points
    5 459
    Par défaut
    Mon problème avec le TDD est le même qu'avec les exigences de tests systématiques et le plus granulaires possibles : c'est trop compliqué (et moins utile) dans les langages à typage statique.

    Certains considèrent qu'un bon code est un code où l'on a ajouté des centaines d'interfaces pour faire baisser le couplage et améliorer la testabilité. Moi j’appelle ça une horreur et un code spaghetti. Et qu'on ne me parle pas des frameworks de mocking : à dose homéopatique, pour des tests importants, pourquoi pas. Mais c'est vite fastidieux.

    La solution serait d'utiliser un sur-ensemble du langage pour les tests avec un runtime dédié : tout appel de méthode ou accès à un champ serait virtuel et pourrait être dynamiquement remplacé (par instance et par type), la visibilité des membre serait relaxée et tout type pourrait être contrefait. Le malus aux performances serait supportable, on conserverait une vérification statique et les tests se feraient très naturellement. Cela aiderait grandement l'écriture de tests dans les langages à typage statique.

  13. #13
    Expert éminent sénior

    Profil pro
    Inscrit en
    janvier 2007
    Messages
    10 591
    Détails du profil
    Informations personnelles :
    Âge : 64
    Localisation : France

    Informations forums :
    Inscription : janvier 2007
    Messages : 10 591
    Points : 17 398
    Points
    17 398
    Billets dans le blog
    2
    Par défaut
    Citation Envoyé par Traroth2 Voir le message
    C'est une approche différente de l'approche traditionnelle, où on écrit les tests après avoir codé.
    Je ne sais pas de quelle tradition tu parles
    "Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".

    Consultant indépendant.
    Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
    C, Fortran, XWindow/Motif, Java

    Je ne réponds pas aux MP techniques

  14. #14
    Membre à l'essai
    Profil pro
    Inscrit en
    mai 2002
    Messages
    8
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mai 2002
    Messages : 8
    Points : 13
    Points
    13
    Par défaut Le TDD: une bonne pratique mais pas partout nix tout le temps
    Le TDD est une bonne pratique qui se met en place sur des applications à fort "traffic" (utilisation très courante) et faible complexité fonctionnelle lors de leur création. Je ne l'ai pas vue ailleurs. Sauf peut-être son reflet ou son frère jumeaux: les tests de non régression automatisés qui procèdent de la même démarche mais après le développement (et souvent sur un périmètre partiel, genre les fonctions cœurs de l'application qui sont à la fois critiques et stables).
    Bref, une bonne idée de développeur qui coûte (toujours trop ?) cher dans le développement pour se généraliser.

  15. #15
    Membre du Club
    Profil pro
    Inscrit en
    avril 2007
    Messages
    35
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : avril 2007
    Messages : 35
    Points : 62
    Points
    62
    Par défaut
    Citation Envoyé par Angelsafrania
    Le TDD je connais, j'en fait.
    Le TDD ca reste des tests, pour faire du TDD il faut déjà faire des tests.
    Avec du vrai cycle en V normalement on fait du TDD vu que les tests sont écrits avant la phase de développement (pour les tests de plus haut niveau).
    MAIS LOOOL
    Alors non, le cycle en V, c'est pas du TDD
    Et non, TDD, ça n'a rien à voir avec les tests.
    Le test est juste un prétexte pour "designer" son code. point.
    D'ailleurs, certains un peu extrêmes jettent les tests une fois qu'ils ont fini.
    Ne mélangeons pas TDD avec le test d'une appli.

    Citation Envoyé par benjani13
    Eu... j'ai bossé un an dans une SSI (très grosse, internationale), on ne m'a pas appris a faire les tests sur la plateforme utilisé (un ERP), on ne m'a pas demandé de faire des tests (en gros le chef passait pour dire "Ça marche? ok on livre au client", sans rien vérifier), et une fois livré j'ai jamais eu de nouvelles.
    RE-LOOOL
    C'est vrai qu'un logiciel, une fois qu'on l'a développé, c'est fini, il bouge plus, on ne le modifie plus, le temps s'arrête

    Citation Envoyé par b_free
    Le TDD est une bonne pratique qui se met en place sur des applications à fort "traffic".
    Non, le TDD n'est pas une pratique. C'est une discipline, un état d'esprit, une façon de pensée. Personne, je dis bien personne, ne m'empêchera d'écrire un test avant d'écrire mon code. Si ça plait pas, je m'en vais.

  16. #16
    Invité
    Invité(e)
    Par défaut
    • 15/09/2014, 14h00
      Carhiboux
      Envoyé par Arsene Newman
      ces mêmes résultats révèlent que 40% des sondés ont une expérience moyenne de 16 ans dans le développement logiciel



      (quasi) impossible en France. Quand tu as plus de 15 ans de dev, c'est soit que tu es dans le plus profond des placards et que tu attends sagement une hypothétique retraite, soit que tu es indépendant.




    15 ans ? Vous êtes généreux. Aux yeux de certains / certaines, c'est 8 ans maximum...

  17. #17
    Expert éminent
    Avatar de Matthieu Vergne
    Homme Profil pro
    Consultant IT, chercheur IA indépendant
    Inscrit en
    novembre 2011
    Messages
    2 198
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Consultant IT, chercheur IA indépendant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : novembre 2011
    Messages : 2 198
    Points : 7 390
    Points
    7 390
    Billets dans le blog
    3
    Par défaut
    Citation Envoyé par deusyss Voir le message
    J'en pense que les équipes pensant pouvoir se passer de test se trompe totalement. Comment peux t on espérer créer du code de qualité sans un minimum de test afin de vérifier que ce qu'on a écrit est fonctionnel et répond aux attentes?
    Qui t'as dit que les gens cherchent toujours à faire du code de qualité ? Si tu prends les dév qui font dans la qualité, tu aura surement l'unanimité : les tests sont obligatoires, et se doivent eux-même d'être de qualité. C'est bien parce qu'on fait surtout dans la quantité et la rentabilité qu'on arrive à programmer à moindre test.

    Cela dit, le sans test n'existe pas :

    Citation Envoyé par benjani13 Voir le message
    Eu... j'ai bossé un an dans une SSI (très grosse, internationale), on ne m'a pas appris a faire les tests sur la plateforme utilisé (un ERP), on ne m'a pas demandé de faire des tests (en gros le chef passait pour dire "Ça marche? ok on livre au client", sans rien vérifier), et une fois livré j'ai jamais eu de nouvelles.

    Donc ça existe...
    Il t'a demandé si ça marchait non ? C'est le minimum, ça veut dire que tu es censé avoir testé un tant soit peu, sinon tu n'es pas censé pouvoir répondre à la question. T'es censé être un minimum responsable de ton travail. Une équipe, c'est pas un ensemble de personnes qui passent leur temps à vérifier que leur voisin a fait son boulot. C'est justement un groupe de gens qui peuvent faire confiance à leurs collègues pour faire leur propre boulot correctement, ce qui leur permet de se concentrer sur leur propre tâche pour la faire aussi correctement. Le chef est pas là pour contrôler ton travail et te mettre une note comme à l'école, il est là pour te donner du travail et compter sur toi pour l'obtenir ou l'informer en cas de soucis, qu'il puisse synchroniser l'équipe (autrement dit faire son boulot) correctement lui aussi.
    Site perso
    Recommandations pour débattre sainement

    Références récurrentes :
    The Cambridge Handbook of Expertise and Expert Performance
    L’Art d’avoir toujours raison (ou ce qu'il faut éviter pour pas que je vous saute à la gorge {^_^})

  18. #18
    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 DonQuiche Voir le message
    Mon problème avec le TDD est le même qu'avec les exigences de tests systématiques et le plus granulaires possibles : c'est trop compliqué (et moins utile) dans les langages à typage statique.

    Certains considèrent qu'un bon code est un code où l'on a ajouté des centaines d'interfaces pour faire baisser le couplage et améliorer la testabilité. Moi j’appelle ça une horreur et un code spaghetti. Et qu'on ne me parle pas des frameworks de mocking : à dose homéopatique, pour des tests importants, pourquoi pas. Mais c'est vite fastidieux.
    Il me semble avoir déjà vu cette discussion quelque part, à propos des tests d'intégration

    Je pense qu'il ne faut pas confondre TDD et tests unitaires en isolation. L'un n'implique pas forcément l'autre, on peut faire du TDD avec uniquement des tests d'intégration et on peut faire des tests unitaires isolés sans pratiquer TDD.
    Sur le fond, il s'agit toujours de faire un compromis entre précision, performance et maintenabilité des tests. On ne va pas refaire le débat, mais une suite de tests d'intégration a tendance à devenir lente avec le temps et je trouve, vérifie moins précisément les erreurs mais va effectivement être moins fragile car moins couplée à l'implémentation. Les tests unitaires isolés sont plus précis, plus rapides, plus granulaires mais ont aussi tendance à être plus brouillons à cause de la présence des mocks.

    Citation Envoyé par DonQuiche Voir le message
    La solution serait d'utiliser un sur-ensemble du langage pour les tests avec un runtime dédié : tout appel de méthode ou accès à un champ serait virtuel et pourrait être dynamiquement remplacé (par instance et par type), la visibilité des membre serait relaxée et tout type pourrait être contrefait. Le malus aux performances serait supportable, on conserverait une vérification statique et les tests se feraient très naturellement. Cela aiderait grandement l'écriture de tests dans les langages à typage statique.
    Là, je suis d'accord à 100%. Dans les langages dynamiques, c'est un plaisir d'écrire des tests car on peut trafiquer le système à tester pour le mettre dans la configuration qui nous arrange sans effort grâce au monkey patching. Le seul inconvénient étant l'absence de vérification statique des types.

  19. #19
    Expert confirmé Avatar de DonQuiche
    Inscrit en
    septembre 2010
    Messages
    2 741
    Détails du profil
    Informations forums :
    Inscription : septembre 2010
    Messages : 2 741
    Points : 5 459
    Points
    5 459
    Par défaut
    Citation Envoyé par Luckyluke34 Voir le message
    on peut faire du TDD avec uniquement des tests d'intégration.
    Dans ce cas on fait forcément du TDD allégé puisque les tests n'influencent plus que la surface des choses. Autrement dit on fait du TDD en surface mais en profondeur c'est un modèle classique.

    Ce n'est pas inutile, ça peut même être très pertinent pour concevoir une bibliothèque ou une couche applicative avec un bon rapport bénéfices-coût. Mais ça reste du TDD très partiel.

Discussions similaires

  1. Smoke : Démo technique Intel afin de montrer la puissance des CPUs Multi-Cores
    Par raptor70 dans le forum Développement 2D, 3D et Jeux
    Réponses: 6
    Dernier message: 29/12/2008, 21h32
  2. Réponses: 0
    Dernier message: 05/11/2008, 14h31
  3. Réponses: 4
    Dernier message: 05/09/2007, 15h44
  4. La technique des portail pour les moteur 3D
    Par Heptaeon dans le forum Algorithmes et structures de données
    Réponses: 4
    Dernier message: 11/10/2005, 16h57
  5. [debutant][JNI]Stocker des objet pour les rappeler plus tard
    Par Celenor dans le forum Entrée/Sortie
    Réponses: 7
    Dernier message: 28/03/2004, 01h28

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