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

Les tests unitaires me semblent excellents, mais je ne suis pas sûr que je devrais passer du temps à l’apprendre à moins de pouvoir convaincre les autres que leur valeur est significative. Je dois convaincre les autres programmeurs et, plus important encore, les compteurs de bean dans la gestion, que tout le temps supplémentaire passé à apprendre le framework de test, à écrire des tests, à les maintenir à jour, etc.

Quelle est la preuve? Quelqu’un a-t-il réellement développé le même logiciel avec deux équipes distinctes, l’une utilisant les tests unitaires et l’autre non, et comparé les résultats? J’en doute. Est-ce que je suis juste censé le justifier avec “Regardez sur Internet, tout le monde en parle, alors ça doit être la bonne chose à faire”?

Où sont les preuves tangibles qui vont convaincre les profanes que les tests unitaires en valent la peine?

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

    [EDIT] Les deux articles ci-dessus mentionnent spécifiquement le 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é-publication. Si vous ne parvenez pas à obtenir les versions en texte intégral, je suggère d’utiliser Google Scholar pour voir si vous pouvez trouver une version accessible au public.

    “Je dois convaincre les autres programmeurs et, plus important encore, les compteurs de bean dans la gestion, que tout le temps supplémentaire consacré à l’apprentissage du framework de test, à la rédaction des tests, à leur mise à jour, etc. ”

    Pourquoi?

    Pourquoi ne pas le faire simplement, discrètement 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.

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

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

    C’est tout ce qu’il faut Personne n’a besoin de savoir que tu le fais. Fais-le.

    Je prends une approche différente à cela:

    Quelle assurance avez-vous que votre code est correct? Ou qu’il ne casse pas l’hypothèse X lorsque quelqu’un de votre équipe change de func1 ()? Sans tests unitaires vous gardant «honnête», je ne suis pas sûr que vous ayez beaucoup d’assurance.

    La notion de maintenir les tests à jour est intéressante. Les tests eux-mêmes n’ont souvent pas à changer. J’ai 3 fois le code de test par rapport au code de production et le code de test a été très peu modifié. 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 monde universitaire, il y a des preuves, mais je n’ai jamais travaillé 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 pris peu de temps pour m’habituer au cadre de test et que les tests d’écriture m’ont vraiment fait réfléchir à mes besoins et à ma conception. n’a écrit aucun test.

    Voici où cela se paye: 1) Vous avez confiance en votre code et 2) Vous attrapez des problèmes plus tôt que vous ne le penseriez. Vous n’avez pas le gars de l’assurance qualité qui dit: “hé, vous n’avez pas pris la peine de vérifier la fonction xyz (), n’est-ce pas? Il n’a pas trouvé ce bogue parce que vous l’avez trouvé il y a un mois. lui, bon pour vous, bon pour l’entreprise et bon pour le client.

    Clairement, c’est 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 heureux et c’est l’objective final.

    Nous avons démontré avec des preuves tangibles qu’il est possible d’écrire un logiciel de merde sans tests unitaires. Je crois qu’il y a même des preuves pour un logiciel de merde avec Unit Testing. Mais ce n’est pas le but.

    Le test unitaire ou le développement piloté par test (TDD) est une technique de conception et non une technique de test. Le code qui est écrit sous forme de test 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 la manière la plus simple de répondre aux questions (et d’apporter des preuves susceptibles d’être contestées par d’autres rapports) qui pourraient être fausses. Même si vous trouvez des preuves tangibles pour votre cas, quelqu’un d’autre pourrait trouver des preuves tangibles.

    Est-ce le travail 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 croient que vous n’avez pas besoin de plus chers?

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

    En savoir plus sur le TDD que sur les tests ssortingctement unitaires, voici un lien vers l’ amélioration de la qualité Réalisation par le développement piloté par les tests: résultats et expériences de quatre équipes indussortingelles , par Nagappan, E. Michael Maximilien, Thirumalesh Bhat et Laurie Williams. document publié par Microsoft Empirical Software Engineering and Measurement Group (ESM) et déjà mentionné ici.

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

    Voici une lecture amusante et amusante d’un gars qui change de compagnie de l’intérieur. Ce n’est pas limité à TDD. http://jamesshore.com/Change-Diary/ Notez qu’il n’a pas persuadé les “compteurs de haricots” pendant un certain temps et a plutôt fait des “tactiques de guérilla”.

    Eh bien, il y a certaines grandes entresockets qui exigent que vous utilisiez des tests unitaires, mais si vous êtes une petite entreprise, pourquoi les imiter?

    Pour moi, lorsque j’ai commencé avec les tests unitaires, il y a de nombreuses années (nous utilisons principalement un modèle de comportement ), c’était parce que je ne pouvais pas contrôler tout le chemin dans une seule application.

    J’étais habitué à la première programmation en bas et à une REPL, donc quand j’ai eu Unit Test (One Test for Every Function), c’était comme ramener une REPL dans des langages qui compilaient beaucoup. Il a ramené le plaisir à chaque ligne de code que j’ai écrite. J’ai senti dieu Je l’ai aimé. Je n’ai pas besoin d’un rapport pour me dire que j’ai commencé à écrire plus rapidement du code. Mon patron n’avait pas besoin d’un rapport pour le remarquer, parce que lorsque nous faisions des choses folles, nous ne manquions soudainement aucun délai. Mon patron n’avait pas besoin d’un rapport pour remarquer que le nombre de bogues “simples” passait de (à beaucoup) à presque zéro à cause de cette chose très étrange d’écriture de code non productif.

    Comme une autre affiche 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 votre unité (object, module, fonction, classe, serveur, cluster).

    Il y a beaucoup d’échecs et de réussites dans le passage à un autre modèle de développement de logiciels dans de nombreuses entresockets.

    Je viens de commencer à l’utiliser chaque fois que j’avais quelque chose de nouveau à écrire. Il y a un vieux dicton qui me rend difficile de traduire en anglais mais:

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

    Juste pour append plus d’informations à ces réponses, il existe deux ressources de méta-parsing qui peuvent aider à déterminer les effets de la productivité et de la qualité sur le contexte académique et indussortingel:

    Introduction des rédacteurs invités: TDD – L’art de la programmation intrépide [ link ]

    Tous les chercheurs semblent convenir que 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 pour la conception des tests est néanmoins encourageante. Si nous considérons les tests comme un échantillonnage d’une très grande 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é des études empiriques choisies sur le développement axé sur les tests: participants de l’indussortinge *

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

    Tableau 2. Résumé des études empiriques choisies sur le TDD: participants académiques *

    entrer la description de l'image ici

    Les effets du développement dirigé par les tests sur la qualité et la productivité externes: une méta-parsing [ link ]

    Abstrait:

    Cet article fournit une méta-parsing 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, la TDD a un léger effet positif sur la qualité, mais qu’elle a peu ou pas d’effet perceptible sur la productivité. Cependant, l’parsing des sous-groupes a révélé que l’amélioration de la qualité et la baisse de la productivité étaient beaucoup plus importantes dans les études indussortingelles 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 processus TDD et le processus du groupe de contrôle était significative. Une amélioration plus importante de la qualité a également été constatée dans les études universitaires lorsque la différence dans l’effort de test est importante; Cependant, aucune conclusion n’a pu être tirée concernant les études indussortingelles 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 modérasortingces 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é.

    Il y a des statistiques qui prouvent que la correction d’un bogue trouvé dans le test d’unité / d’intégration coûte beaucoup moins cher que la réparation une fois sur le système live (elles sont basées sur le suivi de milliers de projets réels).

    Edit : par exemple, comme indiqué, le livre ” Code Complete ” rend compte de telles é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 prouve également.

    Si vous êtes également intéressé par des preuves contre les tests unitaires, voici un article bien documenté et réfléchi:

    Pourquoi la plupart des tests unitaires sont des déchets Par James O Coplien (gourou maigre et agile)

    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 de nombreuses lunes, j’étais un nouveau diplômé travaillant sur un grand projet VB6 et j’ai eu l’occasion d’écrire un grand nombre de codes de procédures stockées. Du sous-système que j’écrivais, il représentait environ 1/4 de la base de code – environ 13 000 LOC sur 50 000 ou plus.

    J’ai écrit une série de tests unitaires pour les procédures stockées, mais les tests unitaires du code VB6 UI ne sont pas vraiment réalisables sans des outils tels que Rational Robot; au moins ce n’était pas à l’époque.

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

    Sans trop de manipulations à la main, vous pouvez atsortingbuer au moins une amélioration de l’ordre de grandeur des taux de défauts aux tests unitaires.