Est 100% de couverture de code une très bonne chose lorsque vous faites des tests unitaires? [fermé]

Question

J'ai toujours appris que faire la couverture maximale du code avec des tests unitaires est bon . J'entends aussi les développeurs de grandes entreprises telles que Microsoft en disant qu'ils écrivent plus de lignes de code test que le code exécutable lui-même.

est-ce vraiment grand? ne pas sembler parfois comme perte totale de temps qui a un effet que rendant plus difficile l'entretien

Par exemple, disons que j'ai un DisplayBooks() de méthode qui alimente une liste de livres à partir d'une base de données. Les exigences du produit indiquent que s'il y a plus d'une centaine de livres dans le magasin, que cent doit être affiché .

Alors, TDD,

1. Je vais commencer par faire un BooksLimit() de test unitaire qui permettra d'économiser deux cents livres dans la base de données, DisplayBooks() d'appel et faire une Assert.AreEqual(100, DisplayedBooks.Count).
2. Ensuite, je vais tester si elle échoue,
3. Alors je vais changer DisplayBooks() en réglant la limite des résultats à 100 et
4. Enfin je vais relancer le test pour voir si elle réussit.

Eh bien, est-il pas beaucoup plus facile d'aller directement à la troisième étape, et ne jamais faire test unitaire BooksLimit() du tout? Et ne l'est pas plus agile, lorsque les exigences changeront de 100 à 200 limite de livres, pour changer un seul caractère, au lieu de changer les tests, l'exécution des tests pour vérifier si elle échoue, changer le code et les tests en cours d'exécution à nouveau pour vérifier si elle réussit?

Note: laisse supposer que le code est entièrement documenté. Dans le cas contraire, certains peuvent dire, et ils auraient raison, que faire des tests unitaires totaux aidera à comprendre le code qui manque de documentation. En fait, ayant un test unitaire de BooksLimit() montrera très clairement qu'il ya un nombre maximum de livres à afficher, et que ce nombre maximum est de 100. Stepping dans le code non-tests unitaires serait beaucoup plus difficile, étant donné que cette limite peut être mis en œuvre si for (int bookIndex = 0; bookIndex < 100; ... ou foreach ... if (count >= 100) break;.

Answer 1

  

Eh bien, est-il pas beaucoup plus facile d'aller directement à la troisième étape, et ne jamais faire des tests unitaires BooksLimit () du tout?

Oui ... Si vous ne passez pas à écrire des tests temps, vous passerez moins de tests d'écriture de temps. Votre projet peut prendre plus Dans l'ensemble, parce que vous allez passer beaucoup de temps à déboguer, mais peut-être plus facile à expliquer à votre manager? Si tel est le cas ... obtenir un nouvel emploi! Le test est crucial pour l'amélioration de votre confiance dans votre logiciel.

UnitTesting donne le plus de valeur quand vous avez beaucoup de code. Il est facile de déboguer une simple affectation de devoirs en utilisant quelques classes sans UnitTesting. Une fois que vous obtenez dans le monde, et vous travaillez dans codebases de millions de lignes - vous en aurez besoin. Vous pouvez tout simplement pas votre seule étape débogueur à travers tout. Vous ne pouvez pas tout comprendre. Vous devez savoir que les classes que vous êtes en fonction des travaux. Vous devez savoir si quelqu'un dit: « Je vais juste faire ce changement du comportement ... parce que je en ai besoin », mais ils ont oublié qu'il ya deux cents autres utilisations qui dépendent de ce comportement. UnitTesting aide à prévenir cela.

En ce qui concerne l'entretien plus difficile faire:. NO WAY Je ne peux pas tirer assez que

Si vous êtes la seule personne qui ait jamais travaillé sur votre projet, alors oui, vous pourriez penser que. Mais c'est fou de parler! Essayez de se lever à la vitesse sur un projet de ligne de 30k sans unittests. Essayez d'ajouter des fonctionnalités qui nécessitent des modifications importantes au code sans unittests. Il y a pas confiance que vous n'êtes pas casser des hypothèses implicites faites par les autres ingénieurs. Pour un mainteneur (ou nouveau développeur sur un projet existant) unittests sont essentiels. J'ai appuyé sur unittests pour la documentation, un comportement, des hypothèses, pour me dire quand je l'ai cassé quelque chose (que je pensais était sans rapport). Parfois, un des tests API mal écrit a mal écrit et peut être un cauchemar pour le changement, parce que les tests sucent tout votre temps. Finalement, vous allez vouloir factoriser ce code et correctif, mais vos utilisateurs vous remerciera pour cela aussi -. Votre API sera beaucoup plus facile à utiliser à cause de cela

Une note sur la couverture:

Pour moi, ce n'est pas sur la couverture de test 100%. 100% de couverture ne trouve pas tous les bugs, envisager une fonction avec deux déclarations de if:

// Will return a number less than or equal to 3
int Bar(bool cond1, bool cond2) {
  int b;
  if (cond1) {
    b++;
  } else {
    b+=2;
  }

  if (cond2) {
    b+=2;
  } else {
    b++;
  }
}

Considérons maintenant j'écris un test que les tests:

EXPECT_EQ(3, Bar(true, true));
EXPECT_EQ(3, Bar(false, false));

C'est une couverture de 100%. C'est aussi une fonction qui ne respecte pas le contrat -. Bar(false, true); échoue, car elle retourne 4. Donc « couverture complète » n'est pas l'objectif final

Honnêtement, je sauter des tests pour BooksLimit(). Il retourne une constante, il est donc probablement pas la peine le temps de les écrire (et il devrait être testé lors de l'écriture DisplayBooks()). Je pourrais être triste quand quelqu'un décide de (à tort) calculer cette limite de la taille de la tablette, et il ne satisfait plus à nos besoins. J'ai été brûlé par « pas de tests valeur » avant. L'année dernière, je l'ai écrit un code que je l'ai dit à mon collègue: « Cette classe est la plupart du temps des données, il n'a pas besoin d'être testé ». Il avait une méthode. Il y avait un bug. Il est allé à la production. Il nous paginée au milieu de la nuit. Je me sentais stupide. J'ai donc écrit les tests. Et puis je réfléchissais longuement sur ce code constitue « pas une valeur test ». Il n'y a pas grand-chose.

Alors, oui, vous pouvez passer des tests. couverture de test 100% est grande, mais cela ne signifie pas comme par magie votre logiciel est parfait. Tout se résume à la confiance face à des changements.

Si ensemble, et je trouve quelque chose que je mets class A, class B et class C qui ne fonctionne pas, je ne veux passer du temps de débogage trois? Non, je veux savoir que A et B déjà rencontré leurs contrats (via unittests) et mon nouveau code class C est probablement cassé. unittes donc jet il. Comment puis-je savoir même c'est cassé, si je ne le fais pas unittest? En cliquant sur quelques boutons et d'essayer le nouveau code? C'est bien, mais pas suffisant. Une fois que votre programme échelles en place, il sera impossible de relancer tous vos tests manuels pour vérifier que tout fonctionne bien. Voilà pourquoi les gens qui automatisent unittest habituellement leurs tests en cours d'exécution aussi. Dites-moi "Pass" ou "Fail", ne me dites pas "la sortie est ...".

OK, va aller écrire d'autres tests ...

Answer 2

100% de couverture de test unitaire est généralement une odeur de code, un signe que quelqu'un est venu sur tous les TOC sur la barre verte dans l'outil de couverture, au lieu de faire quelque chose de plus utile.

Quelque part autour de 85% est le sweet spot, où un test ne plus souvent qui indique pas un problème réel ou potentiel, plutôt que d'être simplement une conséquence inévitable de tout changement à l'intérieur des textes non marqueurs de commentaire. Vous n'êtes pas justifiez les hypothèses utiles sur le code si vos hypothèses sont « le code est ce qu'il est, et si elle était dans une autre façon ce serait quelque chose d'autre ». C'est un problème résolu par un outil de contrôle conscient commentaire, pas un test unitaire.

Je souhaite qu'il y ait un certain outil qui vous permet de spécifier la couverture cible. Et puis si vous allez par hasard sur elle, montrer les choses en jaune / orange / rouge pour vous pousser vers la suppression de certains des tests supplémentaires parasites.

Answer 3

Lorsque l'on regarde un problème isolé, vous êtes tout à fait raison. Mais les tests unitaires sont sur le point couvrant toutes les intentions que vous avez un certain morceau de code.

En fait, les tests unitaires Formulez vos intentions. Avec un nombre croissant d'intentions, le comportement du code à tester peut toujours être vérifiée par rapport à toutes les intentions faites à ce jour. Chaque fois qu'une modification est apportée, vous pouvez prouver qu'il n'y a pas d'effets secondaires qui rompt les intentions existantes. Nouvellement trouvé des bugs ne sont rien d'autre qu'une intention (implicite) qui n'est pas tenu par le code, de sorte que vous formulez votre intention comme nouveau test (qui échoue au premier) et le fixer.

Pour le code unique, les tests unitaires sont en effet pas la peine, car aucun changement majeur sont attendus. Cependant, pour un bloc de code qui doit être maintenu ou qui sert en tant que composant pour d'autres codes, ce qui justifie que toutes les intentions sont tenues pour toute nouvelle version vaut beaucoup (en termes d'effort moins pour essayer manuellement pour vérifier les effets secondaires) .

Le point de basculement où l'unité teste effectivement économiser du temps et donc de l'argent dépend de la complexité du code, mais il y a toujours un point de basculement qui est généralement atteint après seulement quelques itérations de changements. En outre, last but not least, il vous permet d'expédier des corrections et des changements beaucoup plus rapidement sans compromettre la qualité de votre produit.

Answer 4

Il n'y a aucune relation entre exlpicit couverture de code et un bon logiciel. Vous pouvez facilement imaginer morceau de code qui a 100% (ou presque) la couverture de code et il contient encore beaucoup de bugs. (Ce qui ne veut pas dire que les tests sont mauvais!)

Votre question sur l'agilité de « pas de test du tout » approche est bonne pour de courtes perspective (ce qui signifie qu'il est très probablement pas bon si vous envisagez de construire votre programme pour plus de temps). Je sais de mon expérience que ces tests simples sont très utiles lorsque votre projet devient de plus en plus grand et à un certain stade, vous devez apporter des modifications importantes. Cela peut être un momment quand vous dites à vous «Ce fut une bonne décision de passer quelques minutes supplémentaires pour écrire ce petit test qui bug repéré Je viens introduit!" .

J'étais un grand fan de couverture de code récemment, mais maintenant il se (Luckilly) à quelque chose comme couverture des problèmes 'approche . Cela signifie que vos tests devraient couvrir tous les problèmes et bugs qui ont été repérés non seulement 'lignes de code . Il n'y a pas besoin de faire un course de couverture de code .

Je comprends mot « Agile » en termes de tests numériques comme nombre de tests qui me permet de construire un bon logiciel et ne pas perdre le temps d'écrire morceau de code inutile ' plutôt que « 100% de couverture » ou « aucun test du tout ». Il est très subjective et basé sur votre expérience, l'équipe, la technologie et de nombreux facteurs d'autres.

L'effet secondaire psychologique de « 100% de couverture de code » est que vous pouvez penser que votre code n'a pas de bugs, qui n'est vrai:)

Answer 5

Je suis d'accord avec @soru, couverture de test 100% ne sont pas un objectif rationnel.

Je ne crois pas que tout outil ou métrique peut exister qui peut vous dire le montant de la couverture « droit ». Quand j'étais à l'école grad, le travail de mon conseiller en thèse portait sur la conception de la couverture de test pour le code « muté ». Il va prendre une série de tests, puis exécutez un programme automatisé pour faire des erreurs dans le code source sous test. L'idée était que le code muté contenait des erreurs qui se trouvent dans le monde réel, et donc une suite de tests qui trouve le pourcentage le plus élevé d'un code cassé a été le gagnant.

Alors que sa thèse a été acceptée, et il est maintenant professeur à une grande école d'ingénieur, il ne trouve pas non plus:

1) un nombre magique de couverture de test qui est optimal 2) une suite qui pourrait trouver 100% des erreurs.

Note, l'objectif est de trouver 100% des erreurs, de ne pas trouver une couverture de 100%.

Que ce soit à 85% de Soru est juste ou non est un sujet de discussion. Je n'ai pas moyen d'évaluer si un meilleur nombre serait de 80% ou 90% ou quoi que ce soit d'autre. Mais comme une évaluation de travail, 85% se sent à droite pour moi.

Answer 6

Désolé pour mon anglais.

100% de couverture de code est un trouble physiologique de gestion pour impressionner les parties prenantes artificiellement. Nous faire des tests parce qu'il ya un code complexe là-bas ce qui peut conduire à des défauts. Nous devons donc nous assurer que le code complexe a un test, son essai et les défauts sont fixés avant son live.

Nous devrions viser quelque chose de test qui est complexe et pas seulement tout. Maintenant, ce besoins complexes à exprimer en termes de certains numéros métriques qui peut être l'éther complexité cyclomatique, lignes de code, agrégations, etc. couplage ou son point culminant probablement de toutes les choses ci-dessus. Si nous constatons que plus nous métrique devons nous assurer que, cette partie du code est couvert. Voici mon article qui couvre ce qui est le meilleur% pour la couverture de code.

Est-couverture de code 100% vraiment nécessaire?

Answer 7

D'abord 100% est difficile à obtenir en particulier sur les grands projets! et même si vous faites quand un bloc de code est couvert, il ne veut pas dire qu'il fait ce qu'il est censé sauf si votre test affirment toutes les entrées possibles et de sortie (qui est presque impossible).

Alors je ne considère pas un logiciel pour être bien tout simplement parce qu'il a 100% de couverture de code, mais la couverture de code encore une bonne chose d'avoir.

  

Eh bien, est-il pas beaucoup plus facile d'aller directement à la troisième étape, et ne jamais faire des tests unitaires BooksLimit () du tout?

bien avoir ce test, il vous rend assez confiant que si quelqu'un change le code et le test échoue, vous remarquerez que quelque chose ne va pas avec le nouveau code donc vous éviter tout bug potenciel dans votre application

Answer 8

Lorsque le client décide de changer la limite à 200, les bons insectes trouver chance lié à ce test apparemment trivial. Spécialement, lorsque vous avez d'autres 100 variables dans votre code, et il y a d'autres 5 développeurs travaillant sur le code qui repose sur ce petit morceau d'information.

Mon point: si elle est utile à la valeur commerciale (ou, si vous aimez pas le nom, au cœur très important du projet), le tester. Seulement jeter quand il n'y a pas possible (ou pas cher) façon de le tester, comme l'interface utilisateur ou l'interaction de l'utilisateur, ou lorsque vous êtes sûr de l'impact de ne pas écrire ce test est minime. Cela est plus vrai pour des projets avec des exigences vagues, ou de changer rapidement [que je] a découvert à.

Pour l'autre exemple que vous présentez, le recommandé est de tester les valeurs limites. Ainsi, vous pouvez limiter vos tests à seulement quatre valeurs:. 0, un nombre magique entre 0 et BooksLimit, BooksLimit, et un nombre plus élevé

Et, comme d'autres personnes ont dit, faire des tests, mais être quelque chose de positif à 100% d'autre peut échouer.