unit testing - intégration - Existe-t-il des preuves tangibles du retour sur investissement des tests unitaires?




test unitaire php (8)

«Je dois convaincre les autres programmeurs et, surtout, les bean-counters dans la gestion, que tout le temps supplémentaire consacré à l'apprentissage du framework de test, à l'écriture des tests, à leur mise à jour, etc. sera rentabilisé. "

Pourquoi?

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

Les tests unitaires me paraissent très bien, mais je ne suis pas sûr que je devrais vraiment passer du temps à les apprendre à moins de pouvoir convaincre les autres qu'ils ont une valeur significative. Je dois convaincre les autres programmeurs et, plus important encore, les bean-counters dans la gestion, que tout le temps supplémentaire consacré à l'apprentissage du framework de test, à l'écriture des tests, à leur mise à jour, etc. va payer pour lui-même.

Quelle preuve est là? Quelqu'un a-t-il effectivement développé le même logiciel avec deux équipes distinctes, l'une utilisant des tests unitaires et l'autre pas, et a comparé les résultats? J'en doute. Suis-je censé le justifier en disant: «Regardez-le sur Internet, tout le monde en parle, alors ce doit être la bonne chose à faire»?

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


Eh bien, il y a certaines grandes entreprises qui exigent que vous utilisiez 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 behavior ) c'était parce que je ne pouvais pas contrôler tout le chemin dans une application.

J'avais l'habitude de fonder la première programmation et un REPL donc quand j'ai eu le test d'unité (un test pour chaque fonction) c'était comme ramener un REPL dans des langages qui étaient très compilés. Cela a ramené le plaisir à chaque ligne de code que j'ai écrite. Je me sentais dieu. Je l'ai aimé. Je n'avais pas besoin d'un rapport pour me dire que j'ai commencé à écrire de meilleurs codes 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 date limite. Mon patron n'avait pas besoin d'un rapport pour remarquer que le nombre de bogues «simples» tombait de (à beaucoup) à presque rien à cause de cette chose très étrange d'écrire du code non productif.

Comme l'a déjà écrit une autre affiche, 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 d'histoires de succès de passer à un autre modèle de développement de logiciels dans beaucoup d'entreprises.

Je commençais juste à l'utiliser chaque fois que j'avais quelque chose de nouveau à écrire. Il y a un vieux dicton qui va 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 courir 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 aux tests unitaires.

Il y a plusieurs mois, j'étais un jeune diplômé travaillant sur un grand projet VB6 et j'ai eu l'occasion d'écrire un grand nombre de code de procédure stockée. Du sous-système que j'écrivais, il constituait environ le quart de la base du code - environ 13 000 LOC sur 50K environ.

J'ai écrit un ensemble de tests unitaires pour les procédures stockées, mais le test de l'unité VB6 UI code n'est pas vraiment réalisable sans outils comme Rational Robot; Au moins, il n'était pas à l'époque.

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

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


Je prends une approche différente à cela:

Quelle assurance avez-vous que votre code est correct? Ou que cela ne casse pas l'hypothèse X quand quelqu'un de votre équipe change func1 ()? Sans tests unitaires vous gardant «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 3x le code de test par rapport au code de production, et le code de test a été modifié 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 mettre en œuvre la fonctionnalité Y sans casser le système.

Peut-être que dans le monde universitaire, il existe des preuves, mais je n'ai jamais travaillé dans le monde commercial où quelqu'un aurait payé 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 le test d'écriture m'a vraiment fait réfléchir sur mes exigences et le design. n'a pas écrit de tests.

Voici où ça se paie: 1) Vous avez confiance dans votre code et 2) Vous attrapez des problèmes plus tôt que vous 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, il ne trouve pas ce bug 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 content et c'est l'objectif final.


Nous avons démontré avec des preuves solides qu'il est possible d'écrire un logiciel merdique sans tests unitaires. Je crois qu'il y a même des preuves pour un logiciel merdique avec Unit Testing. Mais ce n'est pas le point.

Le test unitaire ou le développement piloté par les tests (TDD) est une technique de conception, pas une technique de test. Le code qui est écrit sur un test écrit 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 façon la plus facile d'aller plus loin 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 solides 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 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é sur la base de la confiance (l'une des valeurs fondamentales des équipes agiles) ou perdu en fonction du pouvoir 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.


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

[EDIT] Les deux articles ci-dessus mentionnent spécifiquement 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 avant la libération. Si vous ne pouvez pas obtenir les versions en texte intégral, je suggère d'utiliser Google Scholar pour voir si vous pouvez trouver une version disponible publiquement.



Voici une lecture amusante et divertissante d'un gars qui change sa 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 fait des "tactiques de guérilla" à la place.





tdd