Y a-t-il des preuves tangibles du ROI des tests unitaires ?

Question

Les tests unitaires sonne bien pour moi, mais je ne suis pas sûr que je devrais passer du temps à apprendre vraiment à moins que je ne peut convaincre les autres de l'est a une valeur importante. J'ai pour convaincre les autres programmeurs et, plus important encore, le haricot-compteurs dans la gestion, que tout le temps consacré à l'apprentissage du framework de tests, essais d'écriture, de les maintenir à jour, etc.. va payer pour lui-même, et puis certains.

Quelle preuve est là? Quelqu'un a fait le même logiciel, avec deux équipes distinctes, l'une utilisant les tests unitaires et l'autre pas, et comparé les résultats? J'en doute. Suis-je censée justifier avec, "un Oeil sur Internet, tout le monde en parle, donc ça doit être la bonne chose à faire"?

Où est la preuve que va convaincre les profanes que les tests unitaires en vaut la peine?

Answer 1

Oui. C'est un lien vers une étude par Boby George et Laurie Williams à ETNC et un autre par Nagappan et coll. Je suis sûr qu'il ya plus. Le dr Williams publications sur les tests peuvent fournir un bon point de départ pour les trouver.

[MODIFIER] Les deux articles ci-dessus spécifiquement référence TDD et de montrer de 15 à 35% d'augmentation dans le développement initial de temps après l'adoption de TDD, mais un 40-90% diminution de la pré-version de défauts. Si vous ne pouvez pas obtenir le texte complet des versions, je vous conseille d'utiliser Google Scholar pour voir si vous pouvez trouver une version publiquement disponible.

Answer 2

"Je convice les autres programmeurs et, plus important encore, le haricot-compteurs dans la gestion, que tout le temps consacré à l'apprentissage du framework de tests, essais d'écriture, de les maintenir à jour, etc.. va payer pour lui-même, et puis certains."

Pourquoi?

Pourquoi ne pas le faire, tranquillement et discrètement. Vous n'avez pas à faire tout à la fois. Vous pouvez le faire en petit morceaux.

Le cadre d'apprentissage prend très peu de temps.

La rédaction d'un essai, d'un seul, prend très peu de temps.

Sans tests unitaires, tout ce que vous avez est une certaine confiance dans votre logiciel. Avec une unité de test, vous avez encore votre confiance, en plus de la preuve qu'au moins un test passe.

C'est tout ce qu'il faut. Nul besoin de savoir que vous êtes à le faire. Juste de le faire.

Answer 3

- Je prendre une autre approche:

Quelle assurance avez-vous que votre code est correct? Ou qu'il ne rompt pas l'hypothèse X lorsque quelqu'un sur votre équipe de changements func1()? Sans les tests unitaires vous garder "honnête", je ne suis pas sûr que vous avez beaucoup d'assurance.

La notion de maintien de tests de mise à jour est intéressante. Les tests eux-mêmes n'ont pas souvent de changer. J'ai eu 3 fois le code de test par rapport à la production de code, et le code de test a été changé très peu. Il 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 l'axe des fonctionnalités sans casser le système.

Peut-être dans le monde universitaire, il y a des preuves, mais je n'ai jamais travaillé ailleurs dans le monde commercial, où tout le monde aurait à payer pour un tel test. Je peux vous dire, cependant, qu'il a bien fonctionné pour moi, a pris peu de temps pour s'habituer à l'infrastructure de test et test écrit m'a fait vraiment penser à mes exigences et la conception, beaucoup plus que j'ai jamais fait lorsque vous travaillez sur des équipes qui écrit pas de tests.

Voici où il paie pour lui-même: 1) Vous avez confiance dans votre code et 2) Vous détecter les problèmes le plus tôt que vous le feriez autrement. Vous n'avez pas l'assurance de la qualité gars dire "hey, vous n'avez pas pris la peine vérification de limites xyz() de la fonction, avez-vous? Il n'a pas de bug parce que vous avez trouvé il y a un mois. Ce qui est bon pour lui, bon pour vous, bon pour la société et bon pour le client.

Clairement, c'est anecdotique, mais il a fait des merveilles pour moi. Pas sûr que je peux vous fournir des feuilles de calcul, mais mon client est heureux et c'est le but de la fin.

Answer 4

Nous avons démontré avec une preuve tangible qu'il est possible d'écrire un logiciel de merde sans Tests Unitaires. Je crois qu'il y a même des preuves pour logiciel de merde avec des Tests Unitaires. Mais ce n'est pas le point.

Unité de Test ou de Développement Piloté par les tests (TDD) est une technique de Conception, pas une technique de test. Le Code est écrit de tester l'air complètement différente de 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 facile pour aller en bas de la route et de répondre à des questions (et d'apporter des éléments de preuve qui pourraient être contestés par d'autres rapports) qui pourraient être posées mal. Même si vous trouvez des preuves tangibles pour votre cas, quelqu'un d'autre peut trouver des preuves tangibles contre.

C'est à l'entreprise de les compteurs de haricots afin de déterminer comment la technique, les gens doivent travailler? Sont-ils en fournissant le moins cher des outils dans tous les cas, parce qu'ils croient que vous n'avez pas besoin de plus cher?

Cet argument est soit de ne basés sur la confiance (une des valeurs fondamentales des équipes de développement agile) ou perdu basée sur le rôle de la puissance de la partie gagnante. Même si le TDD-les promoteurs de gagner basée sur le rôle de la puissance que j'avais le considérer comme perdu.

Answer 5

Voici une lecture grande et amusante d’un mec changer son entreprise de l’intérieur. Il n’est pas limité à TDD. http://jamesshore.com/change-Diary/ Notez qu’il n’a pas de persuader les « compteurs de haricots » depuis un certain temps et qu’il a plutôt les « tactiques de guérilla ».