Discussion :

[Arsene Newman]

Le TDD est mort ? Non, pas vraiment, peut-être que oui
La communauté agile taraudée par un débat autour du TDD

« Le TDD est mort ? Ou pas ? » Telle est la question qui taraude l’esprit de la communauté agile en ce moment, vu l’importance du TDD (Test Driven Development – Développement piloté par les tests) dans l’une des méthodes agiles les plus réputées : la méthode XP.

À l’origine de ce débat houleux, David Heinemeier Hansson (DHH) auteur de Ruby on rails et fondateur du Basecamp et ses deux posts intitulés : « TDD is Dead – Long Live Testing » et « Test-induced design damage».

Dans les faits, DHH critique ouvertement le TDD en notant certaines mauvaises pratiques telles que :

• Concevoir le modèle de son application à partir des tests unitaires n’est pas bénéfique.
• Trop se focaliser sur les tests unitaires ne permet pas de concevoir de bons systèmes, de plus cela fait oublier généralement les tests systèmes.
• Les développeurs pensent que le développement logiciel est une science, alors que cela ressemble plus à de l’écriture et à la créativité.

Les critiques à son encontre n’ont pas tardé à fuser de toute part et dans tous les sens, mais une chose est sure, les réponses ont mis l’accent sur la nécessité d’appliquer le TDD de manière pragmatique.

À titre d’exemple, Robert Martin, développeur logiciel de renom, estime pour sa part que : « si l’on ne fait pas de TDD ou quelque chose d’aussi efficace, alors on devrait se sentir mal ». Il explique aussi pourquoi les développeurs ont recours au TDD :

• Le TDD se traduit par moins de débogage.
• Les tests font office de documentations exactes, précises et sans équivoque au plus petit niveau du système.

D’autres ont répondu à cette critique dans un nouveau post. C’est le cas de Gergely Brautigam qui a posté un article intitulé « TDDD is Dead – Not really ». Ce dernier explique que le TDD ne peut être mort avec autant d’adeptes et qu’à l’image d'autres concepts informatiques, cela ne peut avoir lieu. Il estime que le TDD pourrait évoluer vers quelques choses de nouveau, de mieux comme beaucoup d’autres concepts en informatique.

Aussi, pour Gergely Brautigam, il est important d’avoir des tests à différents niveaux même si de telles pratiques sont rarement appliquées vu le rythme de développement effréné et le stress que subissent les développeurs, ce qui donne lieu à des négligences en matière de qualité de code.

Enfin, un autre intervenant, Gil Zilberfeld, cite un passage du manifeste agile : « nous découvrons de meilleures façons de développer des logiciels en les faisant et en aidant les autres à le faire . Un passage lourd de sens, comme pour dire que le TDD n’est qu’un outil et une manière de faire parmi tant d’autres après tout.


Et vous ?

Que pensez-vous du TDD ?

Pensez-vous que le TDD est un concept révolu ?

[transgohan]

Concevoir le modèle de son application à partir des tests unitaires n’est pas bénéfique.

Il y a vraiment des projets où c'est appliqué ?
C'est comment avoir un projet mort-né...
Le test unitaire n'est pas représentatif d'un logiciel, il n'est représentatif que d'une fonction dans le code (et je fais bien le distingo entre fonction du code et fonctionnalité du système !).

C'est comme vouloir concevoir une maison à partir des spécificités d'une pierre...
A l'époque des hommes des cavernes ça marchait sans doute...
Mais à notre époque c'est construire la pire maison qui soit en se limitant à cela.

[Grimly]

@transgohan :

Oui c'est appliqué
C'est un bon moyen d'entretenir des tests car personne n'aime rédiger des tests unitaires sur un programme qu'il a lui même écrit ou qu'un autre a écrit avec ses pieds.
Avoir des tests veux dire que la plupart des régressions sont perçues à l'avance.

C'est très difficile à appliquer car personne n'aime les tests, du coup il faut un responsable technique qui ait les c***lles de l'imposer sur le projet et de refuser les codes qui ne sont pas nécessaire pour faire passer des tests.

[TheLastShot]

Il n'y a que moi que ça énerve cette mode (Je dis mode parce que depuis un petit moment il y en a de plus en plus, mais le phénomène date surement) du développeur à la science infuse. J'ai l'impression qu'à partir du moment où quelqu'un a fait UN truc qui marche il détient LA vérité suprême et unique, comme si c'était le messie... "Machin pense que le TDD est mort", "Bidule affirme que dans 10 ans truc sera enterré", "Chubaka prédit la fin du langage iWok d'ici la fin de l'année".

En ce qui concerne les TDD je pense que c'est un très bon moyen de s'assurer de la fiabilité du code et de repérer les éventuels erreurs lors du refactoring.
(Exemple de process : on écrit 10 fonctions avec les tests associés. Par la suite quelqu'un touche au code sans vérifier que les tests étaient toujours valide. On revient à notre code en écrivant une nouvelle fonction F qui utilise plusieurs des fonctions précédente et on se rend compte que celle-ci plante... Grâce au test on peut trouver (plus ou moins) directement ce qui ne fonctionne pas, alors que sans les tests on doit débugger, mettre les mains dans le cambouie sans savoir ou on va, ce qui peut prendre plus de temps).

Le vrai problème c'est qu'il y a beaucoup de "mauvais" codeur qui préfère éviter de faire des tests (ou qui ne savent simplement pas les faire) et qui se retrouve au final à perdre plus de temps quand il faut corriger le code...

[abelar_s]

Oui, ce sont des titres grandioses pour du linkbait et du "viral" facile.
Ce n'est pas le premier à faire de la provoc pour se faire entendre

Par contre, ça a lancé une excellente discussion avec Kent Beck, Martin Fowler et DHH: #isTDDdead sur Google+ :
https://plus.google.com/u/0/events/c...4h4d8mejmat98o

Bon visionnage si vous aimez les vidéos ! (je préfère le texte ^^)

[Fanvan]

Il n'y a que moi que ça énerve cette mode du développeur à la science infuse.

Non, il n'y a pas que toi que ça énerve, mais ça dépasse largement la sphère du microcosme des développeurs, et il va falloir qu'on s'y fasse. Un coup de gueule un peu bien tourné sur un blog ou une déclaration un rien provo et iconoclaste, qui seraient passés inaperçus il y a 20 ans bénéficient immédiatement de la caisse de résonance des réseaux sociaux. C'est épuisant de vivre dans un monde du "untel a dit", mais on y est et il faut vivre avec.

Ça m'énerve d'autant plus que des arguments comme "Les développeurs pensent que le développement logiciel est une science, alors que cela ressemble plus à de l’écriture et à la créativité.", ce n'est pas un argument en soit, et ce n'est pas une position défendable si ce n'est pas étayé par des arguments, sans folklore et sans romantisme déplacé. Ce que je ne comprends pas non plus, c'est cette fulgurance qui lui fait passer du constat : "je ne laisse pas mon développement être guidé par des tests, et tout le monde devrait faire pareil" à "ça va pas être facile de vivre dans un monde non test-driven, mais heureusement, rails est là pour nous secourir." J'exagère à peine. Comme si une technologie pouvait solutionner un problème d'ingénierie fondamentalement transversal auquel toutes les technologies sont confrontées. Ce genre de maladresse, qui tient de la maxime publicitaire, jette une ombre sur le propos.

[_skip]

Personnellement, je suis assez d'accord avec son point. J'utilise plutôt une méthode qui consiste à faire du prototypage, une sorte de POC, puis à refactorer et créer des tests après la validation. Et je crois que c'est logique de penser que le TDD ne correspond pas à cette façon de travailler. Je ne vais pas jusqu'à dire que c'est une mode, c'est une méthode comme les autres, ce qui signifie qu'elle se prête bien à certaines situations et moins bien à d'autres . Le problème c'est que pour tout ce qui est méthodologie agile et autres trucs mainstream, les adeptes sont juste extrêmement dogmatiques.

Il condamne notamment l'interdiction d'avoir recours à des opérations lentes (lire un fichier, interroger une DB). Je reconnais sans difficulté qu'il faut l'éviter si possible, le problème c'est que souvent, c'est un compromis. Tester même succinctement une application qui utilise une base de donnée sans faire de véritables requêtes, c'est assez complexe. Ca peut vous demander d'avoir une abstraction très élevée et de concevoir beaucoup de mock objects. Il suffit d'essayer de mocker un simple "panier d'achat" en mémoire, faisant intervenir différentes entités (Produits, Inventaire etc...) pour se rendre compte que ça demande un paquet de code à la main et que rendre ce type de test possible a aussi des implications sur la conception. Ces tests sont pas forcément écrits une fois pour toutes, ils peuvent demander une maintenance si vous refactorez.
Le danger lorsqu'on veut du tout TDD, c'est de complexifier trop son architecture pour les besoins des tests unitaires, puis de s'enfoncer dans le micro-test. Car le problème qui devient évident lorsqu'on teste une application basée sur une source de données externe, c'est que même si les tests passent, on sait jamais si ça passe tant qu'on ne l'a pas exécutée pour de vrai. A ce moment là, est-ce que ça vaut la peine d'avoir recours intensif au mock si c'est beaucoup de boulot et qu'au final ça prouve pas grand chose??? C'est encore plus vrai si vous utilisez des ORM, pouvez-vous garantir que vos mocks se comportent comme les objets réels (style proxy hibernate)?

Cela nous amène à un autre de ses points, il y a des choses (beaucoup de choses en fait), ou le mieux c'est clairement de se contenter de tests d'intégration de haut niveau. Laisser tomber le test "classe par classe" puis tester des "actions" impliquant plusieurs classes, de véritables transactions qui testent aussi bien les couches métier que les couches inférieures (par exemple accès aux données) sur lesquelles elles reposent. Ce sont des tests plus lourds, longs à exécuter, mais ils sont très proches de la réalité. L'étape plus haut, ce sont les tests pratiqués directement sur l'interface utilisateur, style selenium, qui peuvent aussi avoir un rôle complémentaire intéressant.
Je cite son post en rapport avec ce point :

I rarely unit test in the traditional sense of the word, where all dependencies are mocked out, and thousands of tests can close in seconds. It just hasn't been a useful way of dealing with the testing of Rails applications. I test active record models directly, letting them hit the database, and through the use of fixtures. Then layered on top is currently a set of controller tests, but I'd much rather replace those with even higher level system tests through Capybara or similar.

I think that's the direction we're heading. Less emphasis on unit tests, because we're no longer doing test-first as a design practice, and more emphasis on, yes, slow, system tests. (Which btw do not need to be so slow any more, thanks to advances in parallelization and cloud runner infrastructure).

Je suis 100% d'accord avec ça, tester les opérations au niveau transaction métier, voire au niveau utilisateur, il y a que ça de vrai. Ce sont des tests souvent raisonnablement faciles à écrire et à maintenir vu qu'ils se soucient assez peu de ce qui se passe sous le capot, ainsi vous pourrez refactorer les couches basses sans réécrire la moitié du code de test. Peut être long à exécuter (genre chargement d'un script DB initial qui peut prendre quelques secondes), mais au moins les résultats sont la vérité vraie.
Est-ce que pour autant on devrait plus faire de test unitaires (au sens test de classe)? Non du tout, j'y ai recours assez souvent quand je teste des algos pointus qui doivent absolument être blindés. Il m'arrive même d'appliquer le TDD pour ceux-ci. Donc je le répète :

• oui pour le test en général
• oui pour le test unitaire
• non pour le micro-test systématique
• non pour l'obligation stricte d'écrire les tests avant

Après qu'on veuille imposer à un débutant qu'il écrive les tests avant pour le forcer à mener la réflexion sur l'architecture passe encore. Mais l'imposer à un professionnel chevronné, c'est encore du dogmatisme. Il faudrait qu'on commence à comprendre que dans ce métier, il y a pas de standards qui tiennent. On résout des problèmes en prenant des aides partout où on en trouve, que ce soit des outils, des méthodologies, des techniques ou des idées.

[transgohan]

@transgohan :

Oui c'est appliqué
C'est un bon moyen d'entretenir des tests car personne n'aime rédiger des tests unitaires sur un programme qu'il a lui même écrit ou qu'un autre a écrit avec ses pieds.
Avoir des tests veux dire que la plupart des régressions sont perçues à l'avance.

C'est très difficile à appliquer car personne n'aime les tests, du coup il faut un responsable technique qui ait les c***lles de l'imposer sur le projet et de refuser les codes qui ne sont pas nécessaire pour faire passer des tests.

Non mais je suis d'accord pour coder des tests avant de concevoir l'application.
Mais je suis absolument contre le fait de faire une application modélisée à partir de tests unitaires !
C'est aberrant... Car c'est faire de la conception au niveau le plus bas.
Autrement dit c'est bien pire que du cycle en V.
Pour caricaturer c'est en gros au testeur de faire toute l'architecture et la modélisation de l'application finale.
Cela ne vous choque pas ?

Si vous devez avoir vos tests unitaires avant de coder quoi que ce soit c'est que vous avez fait toute la conception jusqu'au niveau le plus bas. Vous avez pensez à la moindre classe, la moindre fonction, le moindre opérateur... C'est une folie !
C'est complètement anti-agile c'est du cycle en V... (et encore, jamais vu de cycle en V aussi poussé...)

[azias]

Dans les faits, DHH critique ouvertement le TDD en notant certaines mauvaises pratiques telles que :

• Concevoir le modèle de son application à partir des tests unitaires n’est pas bénéfique.
• Trop se focaliser sur les tests unitaires ne permet pas de concevoir de bons systèmes, de plus cela fait oublier généralement les tests systèmes.
• Les développeurs pensent que le développement logiciel est une science, alors que cela ressemble plus à de l’écriture et à la créativité.

Il me semble qu'il fait une petite confusion, non? Par définition les tests unitaires ne sont pas fait pour s'appliquer au niveau application/système mais au niveau le plus bas. Contrairement aux tests d'intégration qui eux ne devraient d'ailleurs pas être fait par les développeurs.

Dans ma pratique, les tests unitaires peuvent servir à deux choses: à vérifier le bon comportement de la fonction (ou du composant, du module, de la classe...) par rapport à la spec, ou à rechercher un bug. C'est un peu la même chose techniquement, mais la construction des cas de tests ne sera pas la même, le contexte et la motivation non plus.

Par ailleurs je trouve aussi que la réutilisation des tests unitaires est intéressantes pour comparer deux versions d'une même fonction. D'une part évidemment pour vérifier que les bugs sont bien corrigés et que le reste des fonctionnalités est inchangé, mais aussi pour faire des tests de performance par exemple. Utile quand on récupère des "morceaux" dans le stock open source, choisir entre bibliothèque ou une autre, etc.

Par ailleurs je ne suis pas d'accord avec lui quand il dit que le développement logiciel n'est pas une science. D'une part je ne vois pas la contradiction: la science c'est de la créativité, certain diront même qu'il y a de l'art dans la science. D'autre part la question est de savoir ce qu'on fait de cette créativité? Si on la laisse à l'état brut, on fait n'importe quoi. C'est ce que fait un mauvais développeur. Si on s'en sert comme un point de départ, en organisant les choses de façon rationnelle, en faisant l'effort de comprendre le problème et en étant capable de justifier ce qu'on fait, c'est de la science. Il me semble que c'est ce que fait un bon développeur.

Là où je le rejoindrais peut-être (je ne suis pas certain d'avoir compris le fond de sa pensée) c'est que se fier uniquement aux tests serait une erreur. Sans faire mon serment habituel sur les méthodes formelles, il est tout simplement impossible de tester entièrement une fonction. Ne serait-ce qu'un additionneur 64bits sur nos processeurs actuels. Ça nous fait 2*2^64 cas de tests. Rien que le temps de les réaliser sur un processeur 2Ghz par exemple (disons 2^21 Hz pour simplifier), ça nous fait 2^44 secondes, soit plus de 557 millénaires pour une fonctionnalité aussi simple, et encore il reste à faire la vérification du résultat sur chaque cas de test...

Bref, le test est très utile mais il ne doit pas empêcher de rester intelligent, en particulier dans la façon de faire les tests, sinon on va facilement dans le mûr.

[theMonz31]

oui enfin, le développement ça doit rester fun...

Alors, moi, personnellement, je n'utilise aucune méthode particulière et je m'en porte formidablement bien dans ma tête...

Je n'ai pas un process à respecter à la lettre... et comme je déteste que l'on m'impose quelque chose, je fais à ma sauce des logiciels dont mes
clients sont forts content...

J'aime autant faire des tests fonctionnels et basta...

Bien sur, quand je code mes fonctions, mon expérience fait que j'anticipe (surement une partie) des situations ou il pourrait y avoir des soucis
et donc code le comportement sans avoir à passer un test qui me garantirait que j'ai couvert tous les cas...

Et quand bien même, pourquoi "couvrir" toutes les situations... je ne fais pas de l'embarqué aéronautique.. (j'ai eu fait... je connais, c'est chiant)...

Bref, TDD ou pas TDD... on s'en fout.. l'essentiel est que coder soit Fun, le reste... sinon, on devient des ouvriers à la chaine, contraint par des process...

Apparemment, certains aiment bien celà... Moi, j'suis métal... j'aime pas

[thierry.pericard]

Bonjour,

Sauf erreur de ma part, tout logiciel devrait être testé avant recette purement utilisateur. Après, il faut faire la distinction entre pragmatisme et dogmatisme. Dans tous les cas, il devrait exister au final pour un logiciel :

- des tests unitaires sur au moins les fonctions les plus critiques ou les plus compliquées,
- des tests plus "métiers", écrits en utilisant Selenium par exemple, mais ce n'est sans doute pas la seule solution.

Maintenant, s'il faut passer des heures à débugger des tests à chaque version, c'est que les tests sont mal utilisés. A contrario, l'absence de tests unitaires n'est pas une bonne garantie de l'avenir (hormis les cas de logiciels jetables ou de très courtes durées).

Pour terminer, il faut se rappeler que la détection d'une anomalie coûte beaucoup plus chère qu'elle est découverte le plus tard possible.

[madfu]

Que pensez-vous du TDD ?
Un bon outil, le meilleur que je connaisse en tout cas pour détecter les régressions et appliquer une bonne hygiène de développement, et surtout mieux que rien.

Pensez-vous que le TDD est un concept révolu ?
Révolu non mais réellement consommateur de temps oui quoi qu'en en dise : l'écriture des tests rajoute du temps, et il faut être particulièrement vigilant sur la pertinence des tests (ce qui vient avec l'habitude) parce que l'air de rien la maintenance des tests devient vite consommateur de temps, ce qui implique une réflexion supplémentaire. Dans un monde tout joli tout beau ou le test est accepté comme une composante du projet ça passe, mais en réalité je compte sur les doigts d'une main les clients favorables, surtout dans le monde du service.

[Marco46]

Ecrire une application en 2014 sans tests unitaires et sans mocker chaque dépendance à mon sens c'est pas normal. Il y a une différence qualitative énorme entre une appli testée et une appli non-testée. Et je parle même pas de la capacité à déployer rapidement une nouvelle version.

J'utilise plutôt une méthode qui consiste à faire du prototypage, une sorte de POC, puis à refactorer et créer des tests après la validation.

Ca veut dire quoi créer des tests après validation ? Après validation de la 1er version de l'appli déployée en prod ? Après validation de la 1ère version d'une US ?

Refactorer avant d'écrire les tests c'est vraiment dommage, tu perds une bonne partie de l'intérêt des tests.

Tester même succinctement une application qui utilise une base de donnée sans faire de véritables requêtes, c'est assez complexe.

Pas avec une conception correcte. Il suffit de mocker l'accès à la DB, c'est très simple.

Il suffit d'essayer de mocker un simple "panier d'achat" en mémoire, faisant intervenir différentes entités (Produits, Inventaire etc...) pour se rendre compte que ça demande un paquet de code à la main et que rendre ce type de test possible a aussi des implications sur la conception.

Ah ben oui. Si ta conception ne permet pas de tester unitairement les fonctionnalités de ton panier c'est qu'elle est probablement très mauvaise (classes de 15 bornes de long, fonctions de 15 bornes de long, code spaghetti etc ...)

Ces tests sont pas forcément écrits une fois pour toutes, ils peuvent demander une maintenance si vous refactorez.

De toutes façons tu vas refactorer. Je ne connais pas d'application développée sur un premier qui passe en prod et qui n'a qu'une seule version.
Donc oui tes tests vont suivre mécaniquement l'évolution de l'application, c'est même obligatoire.

Où est le soucis ?

Le danger lorsqu'on veut du tout TDD, c'est de complexifier trop son architecture pour les besoins des tests unitaires, puis de s'enfoncer dans le micro-test.

99% de couverture de code pour les tests en 2014 pour une équipe de dev c'est un attendu qui me semble normal.
Le danger de ne pas tester c'est que quand tu livres t'es en aveugle, tu ne sais pas si ton appli va régresser, ni quelles fonctionnalités vont régresser, bref tu y vas au petit bonheur la chance, ce n'est pas très pro dans la mesure où on a les outils pour gérer ce problème.

Entre le micro-test et le petit-bonheur la chance, comme défaut je préfère de très loin le 1er.

Car le problème qui devient évident lorsqu'on teste une application basée sur une source de données externe, c'est que même si les tests passent, on sait jamais si ça passe tant qu'on ne l'a pas exécutée pour de vrai.

Mais ça c'est pas le boulot des tests unitaires. C'est le boulot des tests d'intégration et e2e.

C'est encore plus vrai si vous utilisez des ORM, pouvez-vous garantir que vos mocks se comportent comme les objets réels (style proxy hibernate)?

Un mock ne se comporte pas. Il ne contient aucune autre logique que le return d'une valeur. Si tu as un seul if dans le code d'un mock, tu as un problème.

Cela nous amène à un autre de ses points, il y a des choses (beaucoup de choses en fait), ou le mieux c'est clairement de se contenter de tests d'intégration de haut niveau.

Les tests d'intégrations sont nécessaires, mais ils ne peuvent pas se substituer aux UT.

[transgohan]

Ecrire une application en 2014 sans tests unitaires et sans mocker chaque dépendance à mon sens c'est pas normal. Il y a une différence qualitative énorme entre une appli testée et une appli non-testée. Et je parle même pas de la capacité à déployer rapidement une nouvelle version.

Quand tu as plusieurs centaines de millier de fonction dans un projet penses-tu que cela s'applique ?
Une application sans test ce n'est pas normal, mais les tests unitaires ne sont pas la normalité, il existe bien d'autres tests bien plus pertinents selon le type de projet.

[Marco46]

Quand tu as plusieurs centaines de millier de fonction dans un projet penses-tu que cela s'applique ?

Si t'as des centaines de milliers de fonctions donc probablement pas loin de pareil en nombre de classes t'as ptet un soucis de découpage du projet non ?

Quel rapport avec les tests ?

Tu es écrit une classe, tu écris les tests (si tu TDD tu fais l'inverse). Un code non-testé est un code non-livré. C'est simple à mettre en oeuvre.

Le temps additionnel perdu à écrire les tests est regagné et probablement même en bénéfice par rapport aux demandes d'évol et au débug. Et même au niveau des devs de départ tu y gagnes très rapidement.

Tu y gagnes également sur ta capacité à déployer rapidement une évol ou un fix.

Une application sans test ce n'est pas normal, mais les tests unitaires ne sont pas la normalité, il existe bien d'autres tests bien plus pertinents selon le type de projet.

Tu veux dire qu'on peut tester une application sans la tester ?


Bref, je pense que David Heinemeier Hansson n'a posté rien d'autre qu'un mauvais troll.

[_skip]

Ca veut dire quoi créer des tests après validation ? Après validation de la 1er version de l'appli déployée en prod ? Après validation de la 1ère version d'une US ?

Après validation de la démarche proposée, il arrive quand on fait du développement, qu'on réalise qu'on s'est trompé. D'où la nécessité d'être super flexible et réactif. Surtout quand on est en territoire inconnu et qu'on bosse sur du prototype. Est-ce que tu blindes un prototype autant qu'une application en production si le but c'est de valider un concept? La tolérance aux fautes d'un POC est énorme. Une fois qu'il passe la validation on peut évidemment le refactorer, améliorer la finition et écrire de bons tests ne serait-ce que pour la non régression.
Il y a des développements où on a une spec stricte sur le bureau, d'autres où on est partagé sur les techniques à employer et où c'est à nous de faire une proposition et de donner forme. Je suis malheureusement très souvent dans le 2e cas.

Refactorer avant d'écrire les tests c'est vraiment dommage, tu perds une bonne partie de l'intérêt des tests.

Mais je gagne énormément de temps lorsque je prend en considération les critiques proposées sur les prototypes, qui peuvent être des révisions importantes.

Pas avec une conception correcte. Il suffit de mocker l'accès à la DB, c'est très simple.

Je suis d'avis contraire... c'est beaucoup de boulot d'abstraire suffisamment l'accès aux données. Surtout si comme moi tu exploites très fortement les possibilités d'une base SQL. Et fabriquer de toute pièce des collections d'objets, c'est du job.

Ah ben oui. Si ta conception ne permet pas de tester unitairement les fonctionnalités de ton panier c'est qu'elle est probablement très mauvaise (classes de 15 bornes de long, fonctions de 15 bornes de long, code spaghetti etc ...)

Mais bien sûr...
Tu es exactement dans cette logique qui m'insupporte, genre soit vous faites comme moi ou comme dit la méthodologie XYZ, soit ce que vous faites c'est forcément de la merde.

99% de couverture de code pour les tests en 2014 pour une équipe de dev c'est un attendu qui me semble normal.
Le danger de ne pas tester c'est que quand tu livres t'es en aveugle, tu ne sais pas si ton appli va régresser, ni quelles fonctionnalités vont régresser, bref tu y vas au petit bonheur la chance, ce n'est pas très pro dans la mesure où on a les outils pour gérer ce problème.

Et moi je rejette complètement les règles comme quoi faut à tout prix X% de coverage, comme toutes ces soi-disant vérités ultimes qu'on se force à suivre de façon moutonnière. Pour moi le test c'est comme une assurance, il y a ce que ça coûte, et ce que ça couvre. Si tu veux la couverture de risque la plus élevée, ça coûtera plus cher, et au bout d'un moment tu es obligé de trouver l'équilibre entre un certain risque et un certain coût. Et dans mon expérience, j'ai jugé que dans ma façon de bosser et les problématiques auxquelles je suis confronté, les tests de hauts niveau ont le meilleur rapport qualité prix.
Mais bon c'est une mentalité de chef d'entreprise qui a des ressources et des moyens limités. Si je disposais de temps et d'argent illimité, je dirais en effet que en dessous de 100% de couverture de test je ne livre pas, quitte à pousser le truc jusqu'à se demander si je suis pas plus en train de tester le JDK que mon propre code.

Entre le micro-test et le petit-bonheur la chance, comme défaut je préfère de très loin le 1er.

C'est la 3e pique de ce genre que tu envoies dans ton post. Personne n'est sur ce forum pour prouver quelque chose aux autres, donc tes présomptions arrogantes, tu peux te les garder.

[Marco46]

Je suis d'avis contraire... c'est beaucoup de boulot d'abstraire suffisamment l'accès aux données. Surtout si comme moi tu exploites très fortement les possibilités d'une base SQL. Et fabriquer de toute pièce des collections d'objets, c'est du job.

Une requête SQL (SELECT) ça renvoie soit un objet (un ensemble de rubriques), soit une collection d'objet. Ce n'est pas compliqué de mocker la fonction qui te renvoie ça.

Mais bien sûr...
Tu es exactement dans cette logique qui m'insupporte, genre soit vous faites comme moi ou comme dit la méthodologie XYZ, soit ce que vous faites c'est forcément de la merde.

C'est pas la méthodologie XYZ, c'est un ensemble de bonnes pratiques. Avoir un code concis qui fait une chose et une seule chose. Et injecter les dépendances nécessaires. Si tu fais ça ton code est testable. Si tu fais pas ça ton code est obligatoirement plus dur à lire et à tester, voire même impossible à tester.
Si tu as d'autres manières de faire je suis preneur.

Et moi je rejette complètement les règles comme quoi faut à tout prix X% de coverage, comme toutes ces soi-disant règles qu'on se force à suivre de façon moutonnière.

Dont acte ya pas de soucis.

Pour moi le test c'est comme une assurance, il y a ce que ça coûte, et ce que ça couvre. Si tu veux la couverture de risque la plus élevée, ça coûtera plus cher, et au bout d'un moment tu es obligé de trouver l'équilibre entre un certain risque et un certain coût.

Ca coute plus cher à l'instant T, pas sur l'ensemble du cout du projet.

Et dans mon expérience, j'ai jugé que dans ma façon de bosser et les problématiques auxquelles je suis confronté, les tests de hauts niveau ont le meilleur rapport qualité prix.

Dont acte c'est ton opinion, je pense que tu te trompes.

Mais bon c'est une mentalité de chef d'entreprise qui a des ressources et des moyens limités. Si je disposais de temps et d'argent illimité, je dirais en effet que en dessous de 100% de couverture de test je ne livre pas, quitte à pousser le truc jusqu'à se demander si je suis pas plus en train de tester le JDK que mon propre code.

Quand je dis 100% de couverture de code, c'est 100% de couverture sur son propre code, il ne s'agit pas de tester que le JDK fonctionne ou qu'une dépendance externe fonctionne normalement :/

C'est la 3e pique de ce genre que tu envoies dans ton post. Personne n'est sur ce forum pour prouver quelque chose aux autres, donc tes présomptions arrogantes, tu peux te les garder.

Ce n'est pas une pique arrogante, je veux juste mettre en évidence que sans tests et sans couvrir la plus grande portion de code possible tu es en mode petit bonheur la chance. Tu le dis toi même quelques lignes au dessus : "Pour moi le test c'est comme une assurance, il y a ce que ça coûte, et ce que ça couvre. . Si tu veux la couverture de risque la plus élevée [...]"

Je ne suis pas du tout d'accord c'est sur le cout. Sur l'ensemble du projet ça ne coute pas plus cher c'est faux faux faux archi faux.

En quoi est-ce arrogant de dire ça ?

[Luckyluke34]

Le test unitaire n'est pas représentatif d'un logiciel, il n'est représentatif que d'une fonction dans le code (et je fais bien le distingo entre fonction du code et fonctionnalité du système !).

C'est comme vouloir concevoir une maison à partir des spécificités d'une pierre...

En fait quand il parle de "Concevoir le modèle de son application à partir des tests unitaires", il ne décrit pas une situation où la réflexion sur les micro-spécificités viendrait avant la conception d'ensemble, ce qui est en effet absurde. Il regrette plutôt que le fondamentalisme des tests unitaires engendre des mutations néfastes sur le design global, car tout tester en isolation à l'extrême nécessite d'ajouter couche d'abstraction après couche d'abstraction. Pour lui, cela rend le code inutilement complexe, lourd, coûteux et sensible aux bugs.

Si on creuse et les vidéos données par abelar_s le montrent bien, DHH réfute en fait un style particulier de TDD qui :

• est basé uniquement sur des tests unitaires
• utilise beaucoup de mocks
  (deux choses que tous les praticants de TDD y compris son créateur ne font pas)
• estime que la première valeur des tests est de faire émerger une conception de son modèle objet (et que le filet de régression fourni par les tests est limite secondaire)

Mais c'était visiblement moins fatigant de juste dire "TDD is Dead" que de se rendre compte et d'expliquer tout ça

[transgohan]

Si t'as des centaines de milliers de fonctions donc probablement pas loin de pareil en nombre de classes t'as ptet un soucis de découpage du projet non ?

Quel rapport avec les tests ?

Tu es écrit une classe, tu écris les tests (si tu TDD tu fais l'inverse). Un code non-testé est un code non-livré. C'est simple à mettre en oeuvre.

Le temps additionnel perdu à écrire les tests est regagné et probablement même en bénéfice par rapport aux demandes d'évol et au débug. Et même au niveau des devs de départ tu y gagnes très rapidement.

Tu y gagnes également sur ta capacité à déployer rapidement une évol ou un fix.

Tous les projets ne font pas uniquement 100 lignes... Je te renverrai au nombre de fonction qui se trouvent dans un OS par exemple.
Sachant qu'il existe des projets clés en main dont le noyau de l'OS n'est qu'un bout du produit.
Sur des projets de cette envergure il n'est absolument pas impossible d'atteindre des chiffres qui à priori vous paraissent faramineux.

Tu veux dire qu'on peut tester une application sans la tester ?

Bien sûr que non, tu m'as lu en diagonale à priori.
J'ai écris que les tests unitaires ne sont pas toujours une solution viable.
Il existe d'autres types de test à plus haut niveau et qui restent suivant la taille du projet tout aussi justifié.
Or plus le projet est gros moins les tests unitaires sont justifiables, ils sont généralement plus une perte de temps qu'un gage de qualité.
Quand tu dois mettre dans la balance :
- 2ans de retard car on veut rédiger tous les tests unitaires
- on respecte les délais mais on sait qu'on aura 98% de qualité du produit car on remplace les tests unitaires par des tests de plus haut niveau (système par exemple)
De plus comme on sait que personne n'est capable de livrer une application sans aucun bug même avec une couverture de tests unitaires parfaite le choix est vite fait... (et ce parce que les tests unitaires ne suffisent pas)

[Marco46]

Tous les projets ne font pas uniquement 100 lignes... Je te renverrai au nombre de fonction qui se trouvent dans un OS par exemple.
Sachant qu'il existe des projets clés en main dont le noyau de l'OS n'est qu'un bout du produit.
Sur des projets de cette envergure il n'est absolument pas impossible d'atteindre des chiffres qui à priori vous paraissent faramineux.

Je te repose la question, quel est le rapport avec les tests ?

Bien sûr que non, tu m'as lu en diagonale à priori.
J'ai écris que les tests unitaires ne sont pas toujours une solution viable.
Il existe d'autres types de test à plus haut niveau et qui restent suivant la taille du projet tout aussi justifié.
Or plus le projet est gros moins les tests unitaires sont justifiables, ils sont généralement plus une perte de temps qu'un gage de qualité.
Quand tu dois mettre dans la balance :
- 2ans de retard car on veut rédiger tous les tests unitaires
- on respecte les délais mais on sait qu'on aura 98% de qualité du produit car on remplace les tests unitaires par des tests de plus haut niveau (système par exemple)
De plus comme on sait que personne n'est capable de livrer une application sans aucun bug même avec une couverture de tests unitaires parfaite le choix est vite fait... (et ce parce que les tests unitaires ne suffisent pas)

A te lire on dirait qu'écrire les TU c'est plus long que d'écrire l'application en elle-même. Si tu prends en compte dans ton archi la testabilité de ton code le cout des tests c'est quoi, allez entre 10 et 20% du temps de dev ?
Evidemment avec des devs formés sur le sujet.
Et ce surcout tu le récupères largement sur la maintenance (qui est ce qui coute le plus cher dans un projet pour rappel)

Il existe d'autres types de test à plus haut niveau et qui restent suivant la taille du projet tout aussi justifié.
Or plus le projet est gros moins les tests unitaires sont justifiables, ils sont généralement plus une perte de temps qu'un gage de qualité.

Je pense exactement l'inverse, plus le projet est petit, plus tu peux te passer des tests unitaires. Mais plus le projet est gros, plus le temps de build est long, et plus il faut y aller avec parcimonie avec les tests d'intégration et e2e et donc plus les TU sont pertinents.
Un build qui dépasse 5 mins c'est un build trop long. L'avantage des tests unitaires c'est que tu peux tout couvrir (quelque soit la taille du projet) tout en conservant un temps de build raisonnable. Et ça sera 100fois plus facile à maintenir que des tests d'intégrations qui vont mettre en oeuvre 3 ou 4 couches/composants (db, webservices, interface, ...)

Par ailleurs, plus le projet est gros, plus il y a de chances d'avoir des régressions, plus il y a de bugs, etc ... Donc il ya un intérêt accru à avoir des TU pour compenser l'instabilité du à la taille.

De plus comme on sait que personne n'est capable de livrer une application sans aucun bug même avec une couverture de tests unitaires parfaite le choix est vite fait... (et ce parce que les tests unitaires ne suffisent pas)

Il ne s'agit pas de livrer sans bugs (même si mécaniquement tu en as beaucoup moins), il s'agit d'avoir de la visibilité avant de déployer et de se consolider sur le long terme.

Avec un build de quelques minutes et de bons TU tu livres une version quand tu en as envie. Tu peux livrer plusieurs fois par jour, petit morceau par petit morceau, c'est 100 fois mieux qu'une grosse version tous les 3 mois à l'ancienne.