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 de devoir consacrer du temps à l'apprendre à moins de pouvoir convaincre les autres que cela a une valeur significative. Je dois convaincre les autres programmeurs et, plus important encore, les compteurs de haricots dans la gestion, que tout le temps supplémentaire passé à apprendre le cadre de test, à écrire des tests, à les maintenir à jour, etc. sera rentabilisé, puis certains.
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 simplement censé le justifier par: "Cherchez sur Internet, tout le monde en parle, donc ça doit être la bonne chose à faire"?
Où sont les preuves tangibles qui convaincront 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 un n autre par Nagappan et al. Je suis sûr qu'il y en a plus. Dr Williams publications sur les tests peut 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é-version. Si vous ne pouvez pas accéder aux versions en texte intégral, je vous 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 haricots dans la gestion, que tout le temps supplémentaire passé à apprendre le cadre de test, à écrire des tests, à les maintenir à jour, etc. sera rentabilisé, puis certains. "
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 minuscules.
L'apprentissage du cadre prend très peu de temps.
Écrire un test, un seul, prend très peu de temps.
Sans test unitaire, tout ce que vous avez, c'est une certaine confiance dans 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.
J'adopte une approche différente à cela:
Quelle assurance avez-vous que votre code est correct? Ou que cela ne casse pas l'hypothèse X lorsqu'un membre de votre équipe change func1 ()? Sans tests unitaires pour vous garder "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 n'ont pas souvent à changer. J'ai 3x le code de test par rapport au code de production, et le code de test a été modifié très très peu. C'est cependant ce qui me permet de bien dormir la nuit et la chose qui me permet de dire au client que j'ai confiance 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é nulle part dans le monde commercial où quelqu'un paierait pour un tel test. Je peux vous dire, cependant, que cela a bien fonctionné pour moi, qu'il m'a fallu peu de temps pour m'habituer au cadre de test et que l'écriture du test m'a fait vraiment réfléchir à mes exigences et à la conception, bien plus que moi jamais fait quand on travaillait sur des équipes qui n'avaient pas écrit de tests.
Voici où cela se paie: 1) Vous avez confiance en votre code et 2) Vous détectez des problèmes plus tôt que vous ne le feriez autrement. Vous n'avez pas le gars QA dire "hé, vous n'avez pas pris la peine de vérifier la fonction xyz (), n'est-ce pas? He ne parvient pas à trouver ce bogue parce que yo l'a trouvé il y a un mois. C'est bon pour lui, bon pour vous, bon pour l'entreprise et bon pour le client.
De toute évidence, 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 satisfait et c'est l'objectif final.
Nous avons démontré avec des preuves tangibles qu'il est possible d'écrire des logiciels de merde sans tests unitaires. Je pense qu'il existe même des preuves de logiciels de merde avec les tests unitaires. Mais ce n'est pas l'essentiel.
Le test unitaire ou le développement piloté par les tests (TDD) est une technique de conception, pas une technique de test. Le code écrit piloté par les 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 de suivre la voie et de répondre aux 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 tangibles pour votre cas - quelqu'un d'autre pourrait trouver des preuves tangibles contre.
Est-ce l'affaire des compteurs de haricots de déterminer comment les techniciens doivent 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 de la puissance du rôle, je le considérerais comme perdu.
Plus sur le TDD que sur les tests unitaires, voici un lien vers le 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 papier, 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 découvert que les équipes TDD produisaient un code entre 60% et 90% meilleur (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 terminer leurs projets.
Si vous êtes également intéressé par des preuves contre les tests unitaires, voici un article bien étudié et réfléchi:
Voici une lecture intéressante et divertissante d'un gars qui change son entreprise de l'intérieur. Ce n'est pas limité au 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 utilisé des "tactiques de guérilla".
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 la productivité et de la qualité sur le contexte universitaire et industriel:
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 sur les tâches et une meilleure couverture des tests. Le simple fait de faire 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, plus 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 *
Tableau 2. Résumé de certaines études empiriques sur le TDD: participants universitaires *
Les effets du développement piloté par les tests sur la qualité et la productivité externes: une méta-analyse [ link ]
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 qu'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 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 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 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 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 des développeurs et de la taille des tâches en tant que variables modératrices a été étudiée, et une corrélation positive statistiquement significative a été trouvée entre la taille des tâches et l'ampleur de l'amélioration de la qualité.
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 (ils sont basés 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, "Relative Efficacité des techniques de qualité "). Mais il existe également des recherches privées dans le domaine du conseil qui le prouvent également.
Eh bien, certaines grandes entreprises exigent que vous utilisiez des tests unitaires, mais si vous êtes une petite entreprise, pourquoi imiter les grandes?
Pour moi, lorsque j'ai commencé avec les tests unitaires, il y a de nombreuses années, (aujourd'hui, nous utilisons principalement le modèle 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 et à un REPL donc quand j'ai obtenu le test unitaire (un test pour chaque fonction), c'était comme ramener un REPL aux langues) que là où beaucoup de compilation. Cela a ramené le plaisir à chaque ligne de code que j'ai écrit. Je me sentais dieu. J'ai aimé. Je n'ai pas eu besoin d'un rapport pour me dire que j'ai commencé à écrire un meilleur code plus rapidement. Mon patron n'a pas besoin d'un rapport pour remarquer que parce que nous faisions des trucs fous, nous n'avons soudainement jamais manqué un délai. Mon patron n'a pas eu besoin d'un rapport pour remarquer que le nombre de bogues "simples" passe de (à beaucoup) à presque nul à cause de cela chose étrange d'écrire du 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 ce que votre unité (objet, module, fonction, classe, serveur, cluster) fonctionne.
Il y a beaucoup d'échecs et de réussites à passer à un modèle différent de développement de logiciels dans de nombreuses entreprises.
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 un peu difficile à traduire en anglais, mais:
Commencez avec 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 exécutez 1 mètre, répétez.
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 nouveau 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 la base de code entière - 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; au moins, ce n'était pas à l'époque.
Les statistiques de QA 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 sont originaires des procédures stockées. C'est un défaut par 6500 lignes de code contre 1 par 1000-1 200 environ sur l'ensemble de la pièce. Gardez également à l'esprit 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 de mouvement de la main, vous pouvez attribuer au moins une amélioration d'ordre de grandeur des taux de défauts aux tests unitaires.