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?

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.

«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.

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.

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.

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

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

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.

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".

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 *

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é 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é.

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.

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.

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.