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 , par Arsene Newman, Expert éminent sénior
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 ?


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de deusyss deusyss - Rédacteur/Modérateur https://www.developpez.com
le 15/09/2014 à 7:53
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é.
Avatar de Angelsafrania Angelsafrania - Membre averti https://www.developpez.com
le 15/09/2014 à 9:30
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]
Avatar de abriotde abriotde - Membre éclairé https://www.developpez.com
le 15/09/2014 à 9:32
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).
Avatar de Angelsafrania Angelsafrania - Membre averti https://www.developpez.com
le 15/09/2014 à 10:36
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.
Avatar de Traroth2 Traroth2 - Membre chevronné https://www.developpez.com
le 15/09/2014 à 10:51
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é.
Avatar de valkirys valkirys - Membre expérimenté https://www.developpez.com
le 15/09/2014 à 11:44
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.
Avatar de benjani13 benjani13 - Membre expérimenté https://www.developpez.com
le 15/09/2014 à 11:59
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...
Avatar de Marco46 Marco46 - Expert éminent https://www.developpez.com
le 15/09/2014 à 13:48
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.
Avatar de Carhiboux Carhiboux - Expert éminent sénior https://www.developpez.com
le 15/09/2014 à 14:00
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.
Avatar de Angelsafrania Angelsafrania - Membre averti https://www.developpez.com
le 15/09/2014 à 14:43
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 !
Offres d'emploi IT
Expert application Supply Chain & Achats H/F
Safran - Ile de France - Evry (91)
Responsable de lot / architecte fpga H/F
Safran - Ile de France - Éragny (95610)
Architecte / concepteur électronique numérique H/F
Safran - Ile de France - Éragny (95610)

Voir plus d'offres Voir la carte des offres IT
Contacter le responsable de la rubrique Accueil