Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

« Le TDD est mort » pour le créateur de Ruby on rails
Une position qui divise la communauté agile

Le , par Arsene Newman

44PARTAGES

4  2 
« 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 ?

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de _skip
Expert éminent https://www.developpez.com
Le 10/06/2014 à 13:37
Citation Envoyé par Marco46 Voir le message

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.
6  0 
Avatar de Grimly
Membre averti https://www.developpez.com
Le 09/06/2014 à 16:59
@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.
4  0 
Avatar de ptah35
Membre éclairé https://www.developpez.com
Le 12/06/2014 à 0:30
Ce n'est pas parce que des développeurs qui prétendent pratiquer le TDD ont de mauvaises pratiques que c'est un problème inhérent au TDD.

Bien sûr qu'il ne faut pas concevoir le modèle d'une application à partir des tests unitaire. Bien sûr qu'il ne faut pas négliger les tests d'intégrations et les tests fonctionnels. Et bien sûr que même si elle peut être plus ou moins formelle la programmation n'est pas une science (et ce n'est pas un déshonneur). Mais en quoi est-ce que le fait de renoncer aux tests unitaires pourrait empêcher quelqu'un de penser que le développement est une science ou que les tests sont la base du design d'un logiciel ? Et est-ce que l'abandon des tests unitaire à pour effet la prise de conscience immédiate chez tous les développeur que les tests d'intégrations et les tests fonctionnels sont eux aussi importants ?

Le TDD, l'ATDD ou le BDD ne sont des panacées mais ces techniques ne sont pas responsables des mauvais design ou du manque de compétences de certains développeurs. Non le TDD n'est pas mort.
4  0 
Avatar de abelar_s
Membre actif https://www.developpez.com
Le 09/06/2014 à 19:13
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 ^^)
3  0 
Avatar de Luckyluke34
Membre émérite https://www.developpez.com
Le 10/07/2014 à 11:14
Citation Envoyé par Nemek Voir le message
Soit le coût est nul, soit il est amortissable. Pour qu'il soit amortissable (à coup sûr), il faut que l'activité tende vers l'infini.
Je dirais plutôt que pour qu'il soit amortissable à coup sûr, il faut que le coût des tests soit inférieur au coût des bugs qui atteignent la prod si on ne fait pas ces tests. Par coût des bugs, j'entends coût de diagnostic, de résolution et coût des éventuels dégâts colatéraux en termes de chiffre d'affaires non réalisé, de mauvaise réputation du produit, éventuellement de failles de sécurité à corriger, etc.

Evidemment, le nombre et la gravité de ces bugs dépendent de la criticité et de la complexité du projet, de la techno, de la capacité de l'équipe de dev à faire du code de qualité sans tests (!)... donc c'est très très dur à évaluer avant.

Citation Envoyé par Nemek Voir le message
Tu défendais bec-et-ongle les TUs, on disait simplement que les tests à plus haut niveau ont plus de valeurs car ils font tourner tout ou partie du système. Contrairement au TU qui ne font tourner que des blocs de code.
Les "problèmes" que je vois avec les tests d'intégration (ce qui ne veut pas dire qu'ils ne sont pas utiles) et qui font que pour moi les TU ont toujours leur place :

  • "Voir le camp de départ, l'arrivée mais pas le terrain" : Il est plus difficile d'identifier les cas limites à tester, car plus compliqué de se représenter mentalement comment des valeurs d'entrée vont se propager et ce qu'elles vont déclencher dans tout un système que dans un seul objet. Il est aussi moins aisé d'imaginer comment un certain nombre de sous-composants pourraient faillir puisque le focus est sur le haut niveau. Ceci est d'autant plus vrai dans les applications propices aux side-effects où en cours de chemin on va faire de l'i/o, accéder à une base de données, un service web : autant de mini obstacles à prévoir et qu'on ne voit pas forcément de loin.

  • Performance : Les tests d'intégration sont plus lents puisqu'ils impliquent plus de composants, et c'est encore pire si on inclut ceux qui vont chercher des données en base, sur le disque... Si on veut tester toutes les possibilités (scénarios nominaux, cas limites) dans ce cadre, on multiplie les tests lents et on a une suite de tests qui ne s'exécute plus en quelques secondes mais en minutes voire dizaines de minutes. La boucle de feedback devient poussive et on hésite davantage à faire des modifications car on sait qu'il peut se passer pas mal de temps avant de se rendre compte qu'on a tout cassé.

  • Complexité : Plus les objets sont réutilisés dans différents scénarios au sein de différents graphes (et on sait que la réutilisation c'est plutôt bien), plus les tests d'intégration vont se complexifier. De la duplication va apparaitre dans l'étape de Setup des tests d'intégration puisque le même objet va devoir être instancié et arrangé dans de multiples tests. On pourrait dire qu'il suffit de créer des méthodes helpers de test communes pour effacer cette duplication, mais un problème se pose quand on s'aperçoit qu'il doit être arrangé d'une certaine manière dans un test A, d'une autre dans un test B et encore une autre dans un test C. Ceci multiplié par le nombre d'objets intermédiaires dans le graphe sur lequel porte le tests d'intégration, et si on veut gérer tous les cas, on aboutit souvent à des Setup de tests obèses, qui varient seulement un petit peu à chaque fois.

  • Facilité de diagnostic : Un test d'intégration qui échoue va nécessiter d'analyser une stack trace pour remonter à l'objet défaillant, voire de débugger, alors qu'un test unitaire bien nommé et avec des assertions précises va bien souvent nous amener directement au bloc de code concerné.

  • Rythme de développement : C'est là qu'on peut reboucler avec le sujet d'origine qui est TDD. Quand on écrit les tests avant, on peut considérer chaque boucle "écriture des tests puis du code" comme un fossé qu'on se creuse pour essayer de le franchir ensuite. C'est très agréable quand on peut évoluer par bonds, petit fossé par petit fossé (TU). On n'est jamais loin du bord pour se rattraper en cas de chute. Si ces fossés deviennent de vastes précipices (tests d'intégration) car le travail nécessaire pour faire passer un test s'étend sur des dizaines de minutes ou des heures, ça devient beaucoup plus hasardeux et laborieux, et surtout plus compliqué de faire marche arrière pour repartir sur des bases saines.


Bilan : pour moi il faut des tests haut niveau mais pas que, et il faut des TU, mais pas que.
3  0 
Avatar de _skip
Expert éminent https://www.developpez.com
Le 09/06/2014 à 20:11
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.
3  1 
Avatar de transgohan
Expert éminent https://www.developpez.com
Le 09/06/2014 à 20:37
Citation Envoyé par Grimly Voir le message
@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é...)
2  0 
Avatar de madfu
Membre confirmé https://www.developpez.com
Le 10/06/2014 à 11:11
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.
2  0 
Avatar de Marco46
Modérateur https://www.developpez.com
Le 10/06/2014 à 11:45
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.

Citation Envoyé par Skip

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.

Citation Envoyé par Skip
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.

Citation Envoyé par Skip
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 ...)

Citation Envoyé par Skip
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 ?

Citation Envoyé par Skip
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.

Citation Envoyé par Skip
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.

Citation Envoyé par Skip

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.

Citation Envoyé par Skip

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.
2  0 
Avatar de transgohan
Expert éminent https://www.developpez.com
Le 10/06/2014 à 15:41
Citation Envoyé par Marco46 Voir le message
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.

Citation Envoyé par Marco46 Voir le message
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)
2  0