Recherche d'études de cas sur la façon dont TDD a amélioré la qualité et / ou la vitesse de développement [fermé]

Dans mon entreprise, j'essaie de montrer pourquoi nous devrions faire du TDD. Actuellement, la plupart des développeurs font tout ce qu'ils peuvent pour mener à bien le projet, puis ajoutent des tests unitaires après coup afin de répondre aux mesures du gestionnaire. Tous les exemples d'entreprises réputées faisant du TDD et voyant les avantages seraient grandement appréciés.

Une étude de 4 projets chez IBM et Microsoft. Publié dans la revue Emperical Software Engineering .

Des études empiriques montrent que le développement piloté par les tests améliore la qualité

Un article publié pour la première fois dans la revue Empirical Software Engineering rapporte: "TDD semble être applicable dans divers domaines et peut réduire considérablement la densité de défauts des logiciels développés sans réduction significative de la productivité de l'équipe de développement." L'étude a comparé 4 projets, chez Microsoft et IBM qui utilisaient TDD avec des projets similaires qui n'utilisaient pas TDD ...

Le document comprend 1 étude de cas chez IBM et 3 de Microsoft. Chacune des études de cas compare deux équipes travaillant sur le même produit, utilisant les mêmes langages et technologies de développement, sous le même responsable de niveau supérieur, dont une seule utilisait le développement piloté par les tests (TDD). Aucune des équipes ne savait qu'elle ferait partie de l'étude pendant leurs cycles de développement. L'étude de cas IBM a suivi des équipes développant des pilotes de périphérique. Les cas Microsoft ont suivi des équipes travaillant sur Windows, MSN et Visual Studio.

L'article décrit les pratiques TDD utilisées par les équipes comme des workflows minute par minute, ainsi que des workflows au niveau des tâches ...

Il y a un chapitre sur TDD avec une étude de cas dans le livre récent, "Making Software: What works and why we believe it". Mais vous pourriez être déçu, car si je me souviens bien, l'étude n'a pas révélé de réels avantages pour TDD. L'étude de cas était intéressante de toute façon, et le livre en général est l'un des meilleurs livres sur les logiciels que j'ai lu récemment. Il contient de nombreuses études de cas sur des choses comme la programmation par paires, la révision de code, etc.

Vérifiez certainement ceci: TDD prouvé efficace! Ou est-ce?

... quand Phil Haack a annoncé que la recherche soutient l'efficacité du TDD, j'étais plus que peu intéressé à voir ce que contenait réellement le rapport lié . Phil cite le résumé.

Nous avons constaté que les élèves testés en premier avaient en moyenne plus de tests et, à leur tour, les étudiants qui avaient écrit plus de tests avaient tendance à être plus productifs. Nous avons également observé que la qualité minimale augmentait linéairement avec le nombre de tests programmeurs, indépendamment de la stratégie de développement utilisée.

Phil a évidemment lu le reste du rapport et propose ses morceaux préférés qui semblent faire comme son titre l'indique. Cependant, l'une des choses qui m'inquiètent lorsque je vois des choses qui soutiennent les dernières et meilleures pratiques de développement de logiciels est une forte tendance au biais de confirmation - de rechercher la confirmation des théories actuelles et d'ignorer les contre-indicateurs.

Donc, étant le type curieux et puisque TDD est quelque chose que je garde un œil pour voir si c'est quelque chose que je pourrais vouloir m'adopter un jour, je suis entré dans le rapport ...

... sans aucun doute, le test conduit d'abord à avoir plus de tests par unité fonctionnelle. La question est de savoir si cela est précieux. Cette étude semblerait indiquer que ce n'est probablement pas le cas, du moins si la qualité est votre gain escompté. Mais alors, je ne suis pas surpris que le nombre de tests ne corresponde pas à la qualité, tout comme je ne suis pas surpris que le nombre de lignes de code ne corresponde pas à la productivité.

L'auteur a beaucoup de bons points à dire sur le fait que le TDD n'est pas si efficace (imo malgré le fait qu'il soit pressé de mourir)

regardez combien de temps vous et le client avez passé à tester manuellement le logiciel; comparer cela à une estimation de la durée des tests automatisés de type TDD. Empochez la différence

d'après mon expérience, les tests automatisés de TDD sont d' or car ils fournissent une assurance et éliminent d'énormes quantités de tests manuels

comme l'a souligné Andres F, vous pouvez obtenir ces avantages simplement grâce à des tests automatisés, pas nécessairement TDD - cependant, TDD nécessite des tests automatisés au lieu d'être une réflexion après coup ou agréable à avoir

Être obligé de penser d'abord aux tests vous oblige également à réfléchir aux problèmes de qualité - tels que la modularité, la conception des interfaces, etc. - avant de commencer à écrire du code.

Personnellement, je crois que l'un des plus grands avantages de TDD est que l'écriture du test conserve tout d'abord la spécification de ce que le code doit réellement faire pendant que vous écrivez le code, plutôt que de le comprendre en quelque sorte -comme-vous-code.

vous voulez faire valoir vos arguments: suggérez-vous de le faire pour le prochain projet, puis apprenez-en. S'il s'avère que cela fonctionne très bien pour vous, alors j'espère que vous continuerez à l'utiliser et si cela a pris plus de temps pour faire le projet et / ou passer tout votre temps à écrire des tests au lieu de coder, alors vous allez sûrement le vider comme un échec.

Je pense que la solution du monde réel est (comme la plupart des choses) à mi-chemin, vous voulez des tests mais vous ne voulez pas que les tests soient plus importants que le projet.

(personnellement, je pense que TDD est une mode, sonne bien en théorie, mais en pratique ... pas si bon. Je trouve que les tests d'intégration sont beaucoup plus importants, mais cela pourrait être juste le genre de projets complexes sur lesquels je travaille).

Je travaille avec TDD depuis 2 ans et là où je travaillais à l'époque, nous étions tous réticents à utiliser, y compris les managers, mais cela s'est vite avéré être la bonne chose à faire.

• Découvrir les bogues à un stade précoce.
• Écrire un meilleur code sans même s'en rendre compte.
• Votre code est maintenant plus facile à gérer car, en raison de vos tests, tout est en petits morceaux (nous avions des fonctions de 300 à 400 lignes) idiotes. Maintenant max 30 et tous testés de manière indépendante.

Les gérants ne le sauraient pas car ils sont tous intéressés par une chose "Avez-vous fini". Mais alors ils se plaignent quand le logiciel continue de se casser sans s'en rendre compte. Avec une bonne couverture et des tests sensibles, ce n'est pas la quantité mais la qualité que vous pouvez vraiment voir quand quelqu'un casse une fonctionnalité. Malheureusement, c'est difficile si vous êtes seul. J'ai eu le même problème, car vous devrez peut-être changer le code, par exemple les classes de base, etc. afin de pouvoir rendre certaines parties du logiciel testables.

Je vous donne un exemple: je voulais me moquer du référentiel mais il n'y avait pas d'interface et j'ai besoin d'injecter le référentiel dans ma couche de service et donc d'ajouter / modifier un constructeur partout dans la boutique, cela s'est avéré être un gros problème mais dans à la fin, j'ai plus de 200 tests testant seulement une zone du système et ils ont été impressionnés.

Je fais généralement ce qui suit:

• Je garde mes unités très courtes
• Seulement 1 affirmation. Pas de roulette russe.
• Je teste un scénario positif-négatif et d'exception

En ce qui concerne les études de cas, je le crains, je ne suis pas sûr d'en avoir vu. Vous devez construire votre projet et devenir vos études de cas, ils pourraient aussi être impressionnés.

J'espère que ça aide