Existe-t-il des preuves tangibles du retour sur investissement des tests unitaires?


127

Les tests unitaires me semblent bien, mais je ne suis pas sûr de devoir passer du temps à vraiment les apprendre à moins que je ne puisse convaincre les autres que cela a une valeur significative. Je dois convaincre les autres programmeurs et, plus important encore, les compteurs de haricots en gestion, que tout le temps supplémentaire passé à apprendre le framework de test, à écrire des tests, à les maintenir à jour, etc. sera rentable, et plus encore.

Quelle preuve y a-t-il? Quelqu'un a-t-il réellement développé le même logiciel avec deux équipes distinctes, l'une utilisant des tests unitaires et l'autre non, et comparé les résultats? J'en doute. Suis-je juste censé le justifier par: "Cherchez-le sur Internet, tout le monde en parle, donc ce doit être la bonne chose à faire"?

Où est la preuve tangible qui convaincra les profanes que les tests unitaires en valent la peine?

Réponses:


98

Oui. Ceci est un lien vers une étude de Boby George et Laurie Williams au NCST et une autre de Nagappan et al. Je suis sûr qu'il y en a d'autres. Les publications du Dr Williams sur les tests peuvent fournir un bon point de départ pour les trouver.

[EDIT] Les deux articles ci-dessus font spécifiquement référence au TDD et montrent une augmentation de 15 à 35% du temps de développement initial après l'adoption du TDD, mais une diminution de 40 à 90% des défauts de pré-libération. Si vous ne parvenez pas à accéder aux versions texte intégral, je vous suggère d'utiliser Google Scholar pour voir si vous pouvez trouver une version disponible publiquement.


14
La première étude compare agile + TDD à des projets en cascade, ses résultats seraient plus pertinents si elle avait comparé deux équipes agiles. La deuxième étude mentionne d'autres études qui ont trouvé peu ou pas de bonus de qualité pour les projets TDD. Et lorsque vous comparez les estimations de la direction concernant le temps supplémentaire nécessaire pour le TDD, il est estimé beaucoup plus élevé pour les deux équipes ayant une grande expertise dans le domaine, mais elles ont également une couverture de test 20% inférieure. Cela confirme ma propre expérience, je trouve l'assurance beaucoup plus importante dans les systèmes avec lesquels je n'ai pas encore travaillé, alors que les tests sont un obstacle pour tout le reste.
LearnCocos2D

Aucune des études ne compare un modèle de processus comparable avec uniquement le changement de méthofologie du test. C'est passer le temps utilisé sur UT en fait mieux dépensé par exemple. test du système. Dans l'état actuel des choses, cela pourrait aussi bien être une étude «si nous testons plus intelligemment, cela aide».
Rune FS

1
Alors que se passe-t-il si le coût de la correction des bogues post-publication est de 0,01% du développement total? Le TDD serait un investissement terrible dans ce cas. Et si les bugs sont peu nombreux? Ces% s ne signifient rien sans contexte. Pour être honnête, je n'ai pas encore lu toute l'étude. Mais en l'état, votre message est utile (bons liens) mais ne répond pas à la question concernant le ROI, l'OMI.
Instine le

1
@Instine Heureusement (?) Il y a de bonnes preuves que ce n'est pas le cas. La correction des bogues post-publication est exponentiellement plus chère que les bogues trouvés au début du développement (ce que fait TDD). Dans ce contexte, un coût de 0,01% du développement total pour tous les bogues post-publication semble peu probable. (Pour plus de détails, voir Code Complete , en particulier Boehm et al. , «Understanding and Controlling Software Costs», IEEE Trans Softw Eng (1988)).
Konrad Rudolph

Il est probablement intéressant de noter que la première étude a un échantillon de 24 programmeurs (travaillant par paires, donc 12 équipes). Je ne sais pas quelle serait la taille d'un échantillon statistiquement valide, mais cela semble faible. Peut-être que quelqu'un d'autre le sait?
Zachary Yates

29

«Je dois convaincre les autres programmeurs et, plus important encore, les compteurs de haricots en gestion, que tout le temps supplémentaire passé à apprendre le framework de test, à écrire des tests, à les mettre à jour, etc. sera rentable, et plus encore. "

Pourquoi?

Pourquoi ne pas simplement le faire, tranquillement et discrètement. Vous n'êtes pas obligé de tout faire en même temps. Vous pouvez le faire en petits morceaux.

L'apprentissage du cadre prend très peu de temps.

Écrire un test, un seul, prend très peu de temps.

Sans tests unitaires, tout ce que vous avez, c'est une certaine confiance en votre logiciel. Avec un test unitaire, vous avez toujours votre confiance, plus la preuve qu'au moins un test réussit.

C'est tout ce qu'il faut. Personne n'a besoin de savoir que vous le faites. Simplement fais-le.


9
Les compteurs de haricots ne pouvaient pas distinguer un test unitaire du reste du code si leur vie en dépendait. J'appuie la suggestion de simplement le faire. Il y a cependant une mise en garde: si vous n'êtes pas seul, vous avez besoin que vos collègues développeurs adoptent cette pratique. Sinon, ils casseront vos tests sans le vouloir.
Thomas Eyde

Faites-le et ne leur dites pas, et vendez l'idée à vos collèges pendant la pause-café ;-)
Johan

3
Parce que vous seriez viré lorsque vous ne respectiez pas vos délais?
Andrew

3
@Neko: Les tests unitaires n'ajoutent pas un "peu de surcharge". Ils réduisent la charge de travail globale en évitant tout un flot d'erreurs stupides. Le travail ne grandit pas; il passe simplement d'un mauvais code à de bons tests unitaires et à un bon code.
S.Lott

1
Les compteurs de haricots veulent que leurs ingénieurs fournissent des solutions solides aux problèmes du domaine. Vous pouvez simplement écrire des tests dans le cadre de votre solution. Ils ne remarqueront même pas. S'ils le demandent, vous pouvez simplement leur dire que vous passez plus de temps dessus pour vous assurer qu'il est robuste et ne nécessitera pas de retouche. Si vous leur suggérez d'écrire des tests unitaires, vous demandez leur approbation sur quelque chose dont ils ne savent rien.
Yorkshireman

16

J'adopte une approche différente à ce sujet:

Quelle assurance avez-vous que votre code est correct? Ou que cela ne rompt pas l'hypothèse X quand un membre de votre équipe change func1 ()? Sans les tests unitaires qui vous maintiennent «honnête», je ne suis pas sûr que vous ayez beaucoup d'assurance.

La notion de mise à jour des tests est intéressante. Les tests eux-mêmes ne doivent pas souvent changer. J'ai 3 fois le code de test par rapport au code de production, et le code de test a très peu changé . C'est pourtant ce qui me permet de bien dormir la nuit et ce qui me permet de dire au client que je suis convaincu que je peux implémenter la fonctionnalité Y sans casser le système.

Peut-être que dans le milieu universitaire il y a des preuves, mais je n'ai jamais travaillé nulle part dans le monde commercial où quiconque paierait pour un tel test. Je peux vous dire, cependant, que cela a bien fonctionné pour moi, que j'ai mis peu de temps pour m'habituer au framework de test et que l'écriture de test m'a vraiment fait réfléchir à mes exigences et à la conception, bien plus que je ne l'ai jamais fait lorsque je travaillais dans des équipes qui n'a écrit aucun test.

Voici où cela se paie: 1) Vous avez confiance en votre code et 2) Vous détectez les problèmes plus tôt que vous ne le feriez autrement. Vous ne demandez pas au responsable du contrôle qualité de dire "hé, vous n'avez pas pris la peine de vérifier les limites de la fonction xyz (), n'est-ce pas? Il n'arrive pas à trouver ce bogue parce que vous l'avez trouvé il y a un mois. C'est bon pour lui, bon pour vous, bon pour l'entreprise et bon pour le client.

C'est clairement anecdotique, mais cela a fait des merveilles pour moi. Je ne suis pas sûr de pouvoir vous fournir des feuilles de calcul, mais mon client est satisfait et c'est l'objectif final.


Mon responsable QA était assez pointu mais il ne regardait pas le code, mais il était facile de dire que les limites n'étaient pas vérifiées.
itsmatt

Tout à fait d'accord sur le fait que les tests unitaires vous obligent à réfléchir davantage à votre conception et à votre exactitude plutôt qu'à coder de manière imprudente
chakrit

7
Les clients ne nous paient pas pour écrire des tests. Là encore, ils ne nous paient pas non plus pour écrire du code. Ils nous paient pour résoudre leurs problèmes, et lorsqu'ils sont confrontés, je parie qu'ils veulent aussi que les problèmes restent résolus. Compte tenu des preuves, il est incroyable que les clients ne veulent pas sécuriser leur investissement.
Thomas Eyde

10

Nous avons démontré avec des preuves tangibles qu'il est possible d'écrire des logiciels de merde sans tests unitaires. Je crois qu'il y a même des preuves de logiciels de merde avec les tests unitaires. Mais ce n'est pas le but.

Les tests unitaires ou le développement piloté par les tests (TDD) sont une technique de conception et non une technique de test. Le code écrit piloté par des tests est complètement différent du code qui ne l'est pas.

Même si ce n'est pas votre question, je me demande si c'est vraiment le moyen le plus simple d'aller plus loin et de répondre à des questions (et d'apporter des preuves qui pourraient être contestées par d'autres rapports) qui pourraient être mal posées. Même si vous trouvez des preuves solides pour votre cas, quelqu'un d'autre pourrait trouver des preuves solides contre.

Est-ce la tâche des compteurs de haricots de déterminer comment les techniciens devraient travailler? Fournissent-ils les outils les moins chers dans tous les cas parce qu'ils pensent que vous n'avez pas besoin d'outils plus chers?

Cet argument est soit gagné sur la base de la confiance (l'une des valeurs fondamentales des équipes agiles), soit perdu sur la base du pouvoir de rôle de la partie gagnante. Même si les partisans du TDD gagnent en fonction du pouvoir du rôle, je le considérerais comme perdu.


13
entendre, entendre :) Une grande partie des preuves tangibles du TDD provient également d'équipes très expérimentées qui obtenaient déjà de bons résultats sans elle. TDD a simplement amélioré leurs résultats plutôt que de les créer à partir de rien. Le vrai retour sur investissement est d'embaucher des codeurs décents et de les laisser décider comment faire les choses.
workmad3

"Est-ce la tâche des compteurs de haricots de déterminer comment les techniciens devraient travailler?" -> toutes les décisions commerciales se résument à de l'argent. Encore, bonne réponse, +1
jcollum

@jcollum mais la façon dont vous effectuez votre travail n'a rien à voir avec l'argent et si vous souhaitez que dome one soit responsable, laissez-les décider COMMENT ils font ce que vous leur avez demandé
Rune FS

TDD n'est pas une technique de conception, c'est juste une technique de codage. blog.ploeh.dk/2010/12/22/TheTDDApostate De nombreux commentateurs ne sont pas d'accord pour dire que le TDD implique le refactoring (qui est une technique de conception) mais le refactoring n'implique pas le TDD. On peut refactoriser sans tests, une grande refactorisation complexe affecte de toute façon les tests unitaires, c'est-à-dire que les tests doivent également être refactorisés afin de devenir tout aussi invalide / faux vert; des refactorisations plus simples, beaucoup n'affectent pas les tests, mais le risque d'erreur est moindre - car la refactorisation est simple.
KolA

@KolA eh bien, avec le reflet de 10,5 ans après cette réponse, je pourrais le dire un peu plus défensif aujourd'hui, mais quand même: je ne dis pas que le TDD est la seule technique de conception dont vous aurez jamais besoin et Mark commence par être une bonne technique de conception avant de conclure qu'elle n'en est pas du tout. J'affaiblirais son opinion et dirais que ce ne doit pas être la seule technique de conception. Chaque code que j'ai écrit TDD est différent du code que j'ai écrit sans. J'appellerais cela un résultat du design. Je travaille mieux avec le tableau blanc, les discussions et d'autres outils, en plus de TDD. Mais merci pour le lien
Olaf Kock


6

Plus sur le TDD que les tests strictement unitaires, voici un lien vers l'article Réaliser l'amélioration de la qualité grâce au développement piloté par les tests: résultats et expériences de quatre équipes industrielles , par Nagappan, E. Michael Maximilien, Thirumalesh Bhat et Laurie Williams. article publié par le groupe Microsoft Empirical Software Engineering and Measurement (ESM) et déjà mentionné ici.

L'équipe a constaté que les équipes TDD produisaient un code qui est entre 60% et 90% de mieux (en termes de densité de défauts) que les équipes non TDD. Cependant, les équipes TDD ont mis entre 15% et 35% de plus pour mener à bien leurs projets.


5

Voici une lecture intéressante et divertissante d'un gars qui change d'entreprise de l'intérieur. Ce n'est pas limité au TDD. http://jamesshore.com/Change-Diary/ Notez qu'il n'a pas convaincu les "compteurs de haricots" pendant un certain temps et a plutôt fait des "tactiques de guérilla".


le lien semble intéressant ... à vérifier re: évolution des processus de travail des organisations ...
méchant pâteux

5

Juste pour ajouter plus d'informations à ces réponses, il existe deux ressources de méta-analyse qui peuvent aider à déterminer les effets de productivité et de qualité sur les antécédents universitaires et industriels:

Introduction des éditeurs invités: TDD - L'art de la programmation sans peur [ lien ]

Tous les chercheurs semblent convenir que le TDD encourage une meilleure concentration des tâches et une meilleure couverture des tests. Le simple fait d'avoir plus de tests ne signifie pas nécessairement que la qualité du logiciel sera meilleure, mais l'attention accrue des programmeurs à la conception des tests est néanmoins encourageante. Si nous considérons les tests comme l'échantillonnage d'une très large population de comportements potentiels, davantage de tests signifient un échantillon plus complet. Dans la mesure où chaque test peut trouver un problème important qu'aucun des autres ne peut trouver, les tests sont utiles, surtout si vous pouvez les exécuter à moindre coût.

Tableau 1. Résumé de certaines études empiriques sur le développement piloté par les tests: participants de l'industrie *

https://www.computer.org/cms/Computer.org/dl/mags/so/2007/03/figures/s3024t1.gif

Tableau 2. Résumé de certaines études empiriques sur le TDD: participants universitaires *

entrez la description de l'image ici

Les effets du développement piloté par les tests sur la qualité externe et la productivité: une méta-analyse [ lien ]

Abstrait:

Cet article fournit une méta-analyse systématique de 27 études qui étudient l'impact du développement piloté par les tests (TDD) sur la qualité et la productivité du code externe.

Les résultats indiquent que, en général, le TDD a un petit effet positif sur la qualité mais peu ou pas d'effet perceptible sur la productivité. Cependant, l'analyse de sous-groupes a révélé que l'amélioration de la qualité et la baisse de productivité étaient beaucoup plus importantes dans les études industrielles que dans les études universitaires. Une baisse de productivité plus importante a été constatée dans les études où la différence d'effort de test entre le TDD et le processus du groupe témoin était significative. Une plus grande amélioration de la qualité a également été constatée dans les études universitaires lorsque la différence d'effort de test est substantielle; cependant, aucune conclusion n'a pu être tirée concernant les études industrielles en raison du manque de données.

Enfin, l'influence de l'expérience du développeur et de la taille de la tâche en tant que variables du modérateur a été étudiée, et une corrélation positive statistiquement significative a été trouvée entre la taille de la tâche et l'ampleur de l'amélioration de la qualité.


4

Eh bien, certaines grandes entreprises vous obligent à utiliser des tests unitaires, mais si vous êtes une petite entreprise, pourquoi imiter les grandes?

Pour moi, quand j'ai commencé avec les tests unitaires, il y a de nombreuses années (aujourd'hui, nous utilisons principalement le modèle de comportement ), c'était parce que je ne pouvais pas contrôler tous les chemins dans une seule application.

J'étais habitué à la première programmation et à une REPL, donc quand j'ai eu un test unitaire (un test pour chaque fonction), c'était comme ramener une REPL dans des langages qui compilaient beaucoup. Cela a ramené le plaisir à chaque ligne de code que j'ai écrite. J'ai senti Dieu. Je l'ai aimé. Je n'avais pas besoin d'un rapport pour me dire que j'avais commencé à écrire un meilleur code plus rapidement. Mon patron n'avait pas besoin d'un rapport pour remarquer que parce que nous faisions des choses folles, nous n'avons soudainement jamais manqué une échéance. Mon patron n'a pas eu besoin d'un rapport pour remarquer que le nombre de bogues "simples" passe de (à beaucoup) à presque zéro à cause de cette chose très étrange d'écrire du code non productif.

Comme un autre poster l'a déjà écrit, vous n'utilisez pas TDD pour tester (vérifier). Vous l'écrivez pour capturer la spécification, le comportement de ce que fonctionne votre unité (objet, module, fonction, classe, serveur, cluster).

Il y a beaucoup d'échecs et de réussites de passage à un modèle différent de développement de logiciels dans de nombreuses entreprises.

J'ai juste commencé à l'utiliser chaque fois que j'avais quelque chose de nouveau à écrire. Il y a un vieux dicton qui est un peu difficile pour moi de traduire en anglais mais:

Commencez par quelque chose de si simple que vous ne remarquez pas que vous le faites. Lorsque vous vous entraînez pour un marathon, commencez par marcher 9 mètres et courez 1 mètre, répétez.


Alors, je devrais juste le faire? Il est garanti de fonctionner, et peu importe si personne d'autre ne le fait avec moi?
Raven

En fait, il s'agit d'un test Joel: joelonsoftware.com/articles/fog0000000043.html . Il me semble que vous pourriez avoir plus de problème qu'un manque de l'étude du prix Nobel sur le test unitaire
Jonke

4

Il existe des statistiques qui prouvent que la correction d'un bogue trouvé dans le test unitaire / d'intégration coûte beaucoup moins cher que la correction une fois qu'il est sur le système en direct (elles sont basées sur la surveillance de milliers de projets réels).

Edit : par exemple, comme indiqué, le livre " Code Complete " rend compte de ces études (paragraphe 20.3, "Efficacité relative des techniques de qualité"). Mais il y a aussi des recherches privées dans le domaine du conseil qui le prouvent également.


1
Ceci est couvert dans Code Complete de Steve McConnell , qui est un livre que vous voudrez probablement avoir sur votre étagère pour d'autres raisons.
Robert Rossney

Cela n'est pas lié à la méthode de test, mais au moment où, dans le processus, un bogue est signalé et, en outre, il serait préférable de passer du temps à trouver des bogues dans les spécifications, car le coût de leur résolution lors de leur recherche lors du développement est rapporté jusqu'à 1000 fois plus cher (un facteur de 10 par phase de développement)
Rune FS

OTOH, si vous ne résolvez que les problèmes que les gens rencontrent réellement dans des situations réelles, vous finirez probablement par devoir corriger beaucoup moins de bogues. Il n'est pas non plus clair pour moi que la correction des bogues plus tôt soit vraiment moins chère, car la détection d'un bogue dans une spécification peut nécessiter beaucoup plus d'efforts que la détection du même bogue dans l'implémentation, et la détection du bogue fait partie du coût de la correction de bogue. C'est l'une de ces choses à laquelle tout le monde croit parce que cela semble évident, mais je n'ai jamais vu une étude sonore qui montre l'effet.
LKM

0

J'ai un ensemble de points de données pour cela - d'une expérience qui m'a vendu sur des tests unitaires.

Il y a plusieurs lunes, j'étais un jeune diplômé travaillant sur un grand projet VB6 et j'ai eu l'occasion d'écrire un grand corps de code de procédure stockée. Du sous-système que j'écrivais, il représentait environ 1/4 de l'ensemble de la base de code - environ 13 000 LOC sur 50K environ.

J'ai écrit un ensemble de tests unitaires pour les procédures stockées, mais les tests unitaires du code d'interface utilisateur VB6 ne sont pas vraiment réalisables sans des outils comme Rational Robot; du moins, ce n'était pas à l'époque.

Les statistiques d'AQ sur la pièce étaient qu'environ 40 ou 50 défauts ont été relevés sur l'ensemble du sous-système, dont deux provenaient des procédures stockées. C'est un défaut pour 6500 lignes de code contre 1 pour 1 000 à 1 200 environ sur l'ensemble de la pièce. Gardez à l'esprit également qu'environ 2/3 du code VB6 était un code standard pour la gestion des erreurs et la journalisation, identique dans toutes les procédures.

Sans trop d'agitation manuelle, vous pouvez attribuer au moins une amélioration d'un ordre de grandeur des taux de défauts aux tests unitaires.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.