Discussion :

[Arsene Newman]

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 ?

[deusyss]

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é.

[Angelsafrania]

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]

[abriotde]

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).

[Angelsafrania]

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.

[Traroth2]

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é.

[Invité]

Ç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.

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.

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.

[benjani13]

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...

[Marco46]

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.

[Carhiboux]

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.

[Angelsafrania]

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 !

[DonQuiche]

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.

[souviron34]

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

[b_free]

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.

[Jay13mhsc]

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.

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

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.

[Invité]

• 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...

[Matthieu Vergne]

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 :

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.

[Luckyluke34]

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.

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.

[DonQuiche]

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.