Existe-t-il des études scientifiques sur le TDD qui utilisent le coût total de possession d'un produit comme mesure?

Lorsque je lisais le résumé des travaux antérieurs dans Dogsa T, Batic D.L'efficacité du développement piloté par les tests: une étude de cas industrielle. Journal de la qualité des logiciels. 2011; 19 (4): 643-661. cela m'a frappé que les mesures utilisées dans de nombreuses études autour de TDD sont basées sur des choses comme les lignes de code, les défauts et le temps consacré au développement.

Existe-t-il des études qui se concentrent sur le coût total de possession des produits qui ont été développés en utilisant TDD vs ex développement traditionnel ou test-last?

Je suis particulièrement intéressé par le coût total d'acquisition et les coûts d'exploitation.

Il existe certaines études sur les implications et les avantages de la TDD, mais les résultats sont contradictoires. Certains projets (c'est mon expérience) ont un taux de bogues et un coût de possession inférieurs en raison de l'utilisation de TDD, car le coût de changement d'une fonctionnalité diminue considérablement. Certains autres sont arrêtés.

Certaines études ( voici une diapositive n ° 50) montrent que le nombre de bugs a augmenté avec la couverture. Je suppose qu'une plus grande couverture implique TDD et qu'un nombre plus élevé de bogues implique un coût de possession plus élevé.

De mon point de vue, aucune métrique ou pratique à elle seule ne peut être liée à une meilleure qualité ou à un coût de possession inférieur. Il existe une combinaison de facteurs qui peuvent conduire à une certaine corrélation. Et ces facteurs changent entre les équipes et les projets.

Je pense que nous avons tous entendu des histoires d'équipes, qui ont juste commencé à faire du TDD, à écrire des méthodes de test sur 100 lignes, ce qui (à mon avis) augmente le coût de possession, car la mise à jour de ce test sera coûteuse.

Ma règle pragmatique est que les personnes soucieuses et désireuses d'apprendre , travaillant dans un environnement qui les soutient et leurs idées ont une meilleure qualité et un meilleur coût de possession.

Je n'ai pas d'études spécifiques, mais je peux vous dire par expérience personnelle et par l'expérience d'autres développeurs que je sais que lorsqu'il est appliqué correctement pour des projets moyens et plus importants, le TDD réduit le temps de mise sur le marché, réduit les bugs et les défauts et améliore la qualité du code .

Cela dit, ce ne sont pas des balles d'argent, pouvez-vous écrire un bon code sans TDD? oui, pouvez-vous écrire du mauvais code en utilisant TDD oui. En fonction de votre projet, TDD peut également augmenter considérablement votre coût de possession du code, un bon exemple est la NASA, où le coût par ligne de code est énorme, mais le coût de propriété n'est pas le centre d'intérêt, c'est le manque de défauts.

Lorsqu'il est appliqué correctement, le TDD augmentera vos coûts de départ et votre base de code, mais vous bénéficierez à long terme des tests de régression, de la détection précoce des bogues et d'une meilleure conception du code qui devrait réduire les défauts et les coûts de test et le temps de maintenance, réduisant ainsi le coût global de la possession.