Qu'est-ce qu'un pourcentage de couverture de code raisonnable pour les tests unitaires (et pourquoi)? [fermé]

StackOverflow https://stackoverflow.com/questions/90002

Question

Si vous deviez imposer un pourcentage de couverture de code minimum pour les tests unitaires, peut-être même si vous deviez vous engager dans un référentiel, de quoi s'agirait-il?

Veuillez expliquer comment vous en êtes arrivé à votre réponse (car si vous n'aviez choisi qu'un numéro, j'aurais pu le faire tout seul;)

Était-ce utile?

La solution

Cette prose d’Alberto Savoia répond précisément à cette question (d’une manière amusante et amusante!):

http://www.artima.com/forums/flat. jsp? forum = 106 & amp; thread = 204677

  

Couverture du test Testivus sur

     

Tôt un matin, un programmeur a demandé   le grand maître:

     

«Je suis prêt à écrire des tests unitaires. Quelle couverture de code devrais-je viser?   pour? "

     

Le grand maître a répondu:

     

"Ne vous inquiétez pas de la couverture, écrivez quelques bons tests."

     

Le programmeur sourit, s'inclina et   à gauche.

     

...

     

Plus tard dans la journée, un deuxième programmeur   posé la même question.

     

Le grand maître a souligné un pot de   l'eau bouillante et dit:

     

"Combien de grains de riz dois-je mettre dans ce pot?"

     

Le programmeur, l'air perplexe,   a répondu:

     

“Comment puis-je éventuellement vous dire? Cela dépend du nombre de personnes que vous devez   nourrir, comment ils ont faim, quel autre   la nourriture que vous servez, combien de riz   vous en avez, et ainsi de suite. "

     

"Exactement", dit le grand maître.

     

Le deuxième programmeur sourit, s'inclina,   et à gauche.

     

...

     

Vers la fin de la journée, un troisième   programmeur est venu et a demandé la même   question sur la couverture de code.

     

"Quatre-vingt pour cent et pas moins!", répondit le maître d'une voix sévère,   frappant du poing sur la table.

     

Le troisième programmeur sourit, s'inclina,   et à gauche.

     

...

     

Après cette dernière réponse, un jeune   l'apprenti s'est approché du grand   maître:

     

«Grand maître, aujourd'hui je vous ai entendu répondre à la même question à propos de   couverture de code avec trois différents   réponses. Pourquoi? "

     

Le grand maître se leva de son   chaise:

     

"Venez prendre un thé frais avec moi et laissez-nous en parler."

     

Après avoir rempli leurs tasses avec   fumer du thé vert chaud, le grand   le maître a commencé à répondre:

     

“Le premier programmeur est nouveau et commence tout juste à tester.   En ce moment, il a beaucoup de code et aucun   tests. Il a un long chemin à parcourir;   en se concentrant sur la couverture de code en ce moment   serait déprimant et tout à fait inutile.   Il vaut mieux s’habituer à   écrire et exécuter des tests. Il peut   s'inquiéter de la couverture plus tard. "

     

“Le second programmeur, en revanche, est assez expérimenté à la fois   à la programmation et aux tests. Quand je   répondit en lui demandant combien de grains   de riz je devrais mettre dans un pot, je   l'a aidée à se rendre compte que la quantité de   les tests nécessaires dépendent d'un nombre   de facteurs, et elle connaît ceux   facteurs mieux que moi - c’est sa   code après tout. Il n'y a pas de single,   simple, répondez, et elle est assez intelligente   gérer la vérité et travailler avec   ça. "

     

"Je vois," dit le jeune apprenti,   "Mais s'il n'y a pas un seul simple   répondez, alors pourquoi avez-vous répondu au   troisième programmeur «Quatre-vingts pour cent et   pas moins »?

     

Le grand maître a ri si fort et   fort que son ventre, la preuve qu'il   bu plus que du thé vert,   floppé de haut en bas.

     

“Le troisième programmeur ne veut que des réponses simples - même s’il existe   pas de réponses simples… et alors ne   suivez-les quand même. "

     

Le jeune apprenti et le grisonnant   grand maître a fini de boire leur   thé dans un silence contemplatif.

Autres conseils

La couverture de code est une mesure trompeuse si votre objectif est une couverture à 100% (au lieu de tester à 100% toutes les fonctionnalités).

  • Vous pouvez obtenir 100% en tapant toutes les lignes une fois. Cependant, vous pourriez toujours manquer de tester une séquence particulière (chemin logique) dans laquelle ces lignes sont touchées.
  • Vous ne pouviez pas obtenir un 100% mais vous avez quand même testé tous vos chemins de code utilisés à 80% / freq. Avoir des tests qui testent chaque 'lancer ExceptionTypeX' ou tout garde de programmation défensive similaire que vous avez mis est un 'bon à avoir', pas un 'indispensable'

Confiez-vous donc à vous-même ou à vos développeurs d’être minutieux et couvrez tous les chemins à travers leur code. Soyez pragmatique et ne poursuivez pas la couverture magique à 100%. Si vous supprimez votre code, vous devriez obtenir une couverture supplémentaire de 90%. Utilisez la couverture de code pour mettre en évidence les fragments de code que vous avez manqués (cela ne devrait pas arriver si vous le faites bien .. puisque vous écrivez du code uniquement pour réussir un test. Aucun code ne peut exister sans le test de votre partenaire.)

La couverture de code est excellente, mais la couverture de fonctionnalités est encore meilleure. Je ne crois pas à couvrir chaque ligne que j'écris. Mais je crois en l’écriture de la couverture de test à 100% de toutes les fonctionnalités que je souhaite fournir (même pour les fonctionnalités super cool que j’ai fournies moi-même et qui n’ont pas été abordées lors des réunions).

Je ne me soucie pas d’avoir un code qui n’est pas couvert par les tests, mais je voudrais bien que je refacture mon code et que je finisse par avoir un comportement différent. Par conséquent, la couverture des fonctionnalités à 100% est ma seule cible.

La réponse acceptée est un bon argument - il n’ya pas un seul chiffre qui puisse avoir un sens comme norme pour chaque projet. Il y a des projets qui n'ont tout simplement pas besoin d'une telle norme. À mon avis, la réponse acceptée ne permet pas de décrire comment on pourrait prendre cette décision pour un projet donné.

Je vais tenter le coup. Je ne suis pas un expert en ingénierie de test et serais heureux de voir une réponse plus éclairée.

Quand définir les exigences de couverture de code

Premièrement, pourquoi voudriez-vous imposer une telle norme en premier lieu? En général, lorsque vous souhaitez introduire une confiance empirique dans votre processus. Qu'est-ce que je veux dire par "confiance empirique"? Eh bien, le véritable objectif exactitude . Pour la plupart des logiciels, nous ne pouvons pas savoir cela pour toutes les entrées, nous nous contentons donc de dire que le code est bien testé . Cela est plus facile à comprendre, mais reste une norme subjective: il sera toujours possible de débattre, que vous l’ayez atteint ou non. Ces débats sont utiles et devraient avoir lieu, mais ils révèlent également des incertitudes.

La couverture de code est une mesure objective: une fois que vous avez vu votre rapport de couverture, aucune ambiguïté sur le fait de savoir si les normes ont été respectées est utile. Est-ce que cela prouve l'exactitude? Pas du tout, mais il y a une relation claire entre la qualité du test et la validité du code, ce qui est notre meilleur moyen d'accroître la confiance dans son exactitude. La couverture de code est une approximation mesurable des qualités incommensurables qui nous tiennent à cœur.

Quelques cas spécifiques où l’avoir une norme empirique pourrait ajouter de la valeur:

  • Pour satisfaire les parties prenantes. Dans de nombreux projets, différents acteurs s'intéressant à la qualité logicielle ne participent pas nécessairement au développement quotidien du logiciel (gestionnaires, responsables techniques). , etc.) En disant "nous allons écrire tous les tests dont nous avons vraiment besoin" Ce n’est pas convaincant: ils doivent soit avoir entièrement confiance en eux, soit vérifier avec une surveillance étroite et continue (en supposant même qu’ils possèdent les connaissances techniques pour le faire.) Il est préférable de fournir des normes mesurables et d’expliquer comment ils se rapprochent raisonnablement des objectifs réels.
  • Pour normaliser le comportement des équipes. Mis à part les parties prenantes, si vous travaillez dans une équipe composée de plusieurs personnes écrivant du code et des tests, vous pouvez vous rendre à l'ambiguïté de ce qui est qualifié de "bien testé". ; Est-ce que tous vos collègues ont la même idée du niveau de test suffisant? Probablement pas. Comment conciliez-vous cela? Trouvez une métrique sur laquelle vous êtes tous d'accord et acceptez-la comme une approximation raisonnable. Ceci est particulièrement (mais pas exclusivement) utile dans les grandes équipes, où les chefs de file peuvent ne pas superviser directement les développeurs débutants, par exemple. Les réseaux de confiance importent également, mais sans mesures objectives, il est facile que le comportement du groupe devienne incohérent, même si tout le monde agit de bonne foi.
  • Pour rester honnête. Même si vous êtes le seul développeur et le seul acteur de votre projet, vous pouvez avoir certaines qualités en tête pour le logiciel. Au lieu de procéder à des évaluations subjectives continues de la qualité du test (ce qui nécessite du travail), vous pouvez utiliser la couverture de code comme une approximation raisonnable et laisser les machines la mesurer pour vous.

Quelles mesures utiliser

La couverture de code n'est pas une métrique unique; Il existe plusieurs façons de mesurer la couverture. Laquelle vous pouvez définir comme norme dépend de ce que vous utilisez pour satisfaire cette norme.

Je vais utiliser deux métriques communes à titre d'exemple pour vous permettre de définir des normes:

  • Couverture des instructions : Quel est le pourcentage d'instructions exécutées lors des tests? Utile pour avoir une idée de la couverture physique de votre code: Quelle quantité de code que j'ai écrite ai-je réellement testée?
    • Ce type de couverture prend en charge un argument de correction plus faible, mais est également plus facile à réaliser. Si vous utilisez simplement la couverture de code pour vous assurer que les objets sont testés (et non comme un indicateur de qualité de test au-delà), la couverture de relevés est probablement suffisante.
  • Couverture des branches : lorsqu'il existe une logique de branchement (par exemple, un si ), les deux branches ont-elles été évaluées? Cela donne une meilleure idée de la couverture logique de votre code: combien de chemins d'accès possibles mon code peut-il avoir empruntés?
    • Ce type de couverture est un meilleur indicateur du fait qu’un programme a été testé sur un ensemble complet d’intrants. Si vous utilisez la couverture de code comme meilleure approximation empirique pour assurer votre exactitude, vous devez définir des normes basées sur la couverture des branches ou similaire.

Il existe de nombreux autres paramètres (la couverture des lignes est similaire à la couverture des instructions, mais donne des résultats numériques différents pour les instructions multilignes, par exemple; la couverture conditionnelle et la couverture des chemins sont similaires à la couverture des branches, mais reflètent une vue plus détaillée de la permutations possibles de l’exécution du programme que vous pourriez rencontrer.)

Quel pourcentage exiger

Enfin, revenons à la question initiale: si vous définissez des normes de couverture de code, quel devrait être ce numéro?

J'espère qu'il est clair à ce stade que nous parlons d'une approximation, donc tout nombre que nous choisirons sera intrinsèquement approximatif.

Quelques chiffres à choisir:

  • 100% . Vous pouvez choisir ceci parce que vous voulez être sûr que tout est testé. Cela ne vous donne aucune idée de la qualité des tests, mais vous indique qu'un test d'une qualité quelconque a touché chaque déclaration (ou branche, etc.). Cela nous ramène à nouveau au degré de confiance: si votre couverture est inférieure à 100% , vous savez qu’un sous-ensemble de votre code n’a pas été testé.
    • Certains pourraient dire que c'est idiot, et vous ne devriez tester que les parties de votre code qui sont vraiment importantes. Je dirais que vous ne devriez également conserver que les parties de votre code qui sont vraiment importantes. La couverture de code peut être améliorée en supprimant également le code non testé.
  • 99% (ou 95%, autres chiffres des années 1990 en haut). Approprié dans les cas où vous souhaitez transmettre un niveau de confiance similaire à 100%, mais Laissez-vous une marge de manœuvre pour ne pas vous soucier du coin de code difficile à tester.
  • 80% . J'ai vu ce numéro utilisé plusieurs fois et je ne sais pas exactement d'où il provient. Je pense que cela pourrait être une étrange appropriation illicite de la règle des 80-20; généralement, l’intention ici est de montrer que la plupart de votre code est testé. (Oui, 51% correspondraient également à "la plupart", mais 80% correspondrait davantage à ce que la plupart des gens entendent par ).) Cela convient aux cas intermédiaires où "bien testé". n’est pas une priorité élevée (vous ne voulez pas gaspiller l’effort en tests de faible valeur), mais est suffisamment prioritaire pour que vous souhaitiez toujours avoir une norme en place.

Je n’ai pas vu de chiffres inférieurs à 80% dans la pratique et j’ai du mal à imaginer un cas où l’on les définirait. Le rôle de ces normes est d’augmenter la confiance en la rectitude, et les chiffres inférieurs à 80% ne sont pas particulièrement inspirants. (Oui, c’est subjectif, mais là encore, l’idée est de faire le choix subjectif une fois que vous définissez la norme, puis d’utiliser une mesure objective pour aller de l’avant.)

Autres notes

Ce qui précède suppose que l’objectif est la rectitude. La couverture de code n'est qu'une information; cela peut être pertinent pour d'autres objectifs. Par exemple, si vous êtes préoccupé par la maintenabilité, vous vous souciez probablement du couplage lâche, ce qui peut être démontré par la testabilité, qui peut à son tour être mesurée (à certains modes) par la couverture de code. Votre norme de couverture de code fournit donc une base empirique pour évaluer approximativement la qualité de la "maintenabilité". aussi bien.

Ma couverture de code préférée est 100% avec un astérisque. L'astérisque vient parce que je préfère utiliser des outils qui me permettent de marquer certaines lignes comme des lignes qui "ne comptent pas". Si j'ai couvert 100% des lignes qui "comptent", j'ai terminé.

Le processus sous-jacent est:

  1. Je rédige mes tests pour exercer toutes les fonctionnalités et les cas extrêmes auxquels je peux penser (généralement à partir de la documentation).
  2. Je lance les outils de couverture de code
  3. J'examine les lignes ou les chemins non couverts et ceux que je considère comme non importants ou inaccessibles (en raison d'une programmation défensive) Je marque comme ne comptant pas
  4. J'écris de nouveaux tests pour couvrir les lignes manquantes et améliorer la documentation si ces cas extrêmes ne sont pas mentionnés.

Ainsi, si mes collaborateurs et moi-même ajoutons un nouveau code ou modifions les tests à l'avenir, une ligne brillante nous indique si nous avons oublié quelque chose d'important: la couverture est tombée en dessous de 100%. Cependant, il offre également la flexibilité nécessaire pour gérer différentes priorités de test.

J'aurais un autre anectode sur la couverture de test que je voudrais partager.

Nous avons un énorme projet dans lequel, sur Twitter, j’ai noté que, avec 700 tests unitaires, nous ne pouvions que avoir une couverture de code de 20% .

Scott Hanselman a répondu par un mots de sagesse :

  

Est-ce le bon 20%? Est-ce le 20%   qui représente le code de vos utilisateurs   frapper le plus? Tu pourrais ajouter 50 de plus   teste et ajoute seulement 2%.

Encore une fois, cela revient à mon Testivus sur la couverture de code Réponse. Combien de riz devriez-vous mettre dans le pot? Cela dépend.

Si le monde était parfait, 100% du code serait couvert par des tests unitaires. Cependant, comme ce n’est PAS un monde parfait, c’est une question de temps. Par conséquent, je vous recommande de vous concentrer moins sur un pourcentage spécifique et de vous concentrer davantage sur les domaines critiques. Si votre code est bien écrit (ou au moins un fac-similé raisonnable de celui-ci), il devrait y avoir plusieurs points clés où les API sont exposées à un autre code.

Concentrez vos efforts de test sur ces API. Assurez-vous que les API sont 1) bien documentées et 2) que des cas de test écrits correspondent à la documentation. Si les résultats attendus ne correspondent pas à ceux de la documentation, vous avez un bogue dans votre code, votre documentation ou vos cas de test. Ce qui est bon à contrôler.

Bonne chance!

For a well designed system, where unit tests have driven the development from the start i would say 85% is a quite low number. Small classes designed to be testable should not be hard to cover better than that.

It's easy to dismiss this question with something like:

  • Covered lines do not equal tested logic and one should not read too much into the percentage.

True, but there are some important points to be made about code coverage. In my experience this metric is actually quite useful, when used correctly. Having said that, I have not seen all systems and i'm sure there are tons of them where it's hard to see code coverage analysis adding any real value. Code can look so different and the scope of the available test framework can vary.

Also, my reasoning mainly concerns quite short test feedback loops. For the product that I'm developing the shortest feedback loop is quite flexible, covering everything from class tests to inter process signalling. Testing a deliverable sub-product typically takes 5 minutes and for such a short feedback loop it is indeed possible to use the test results (and specifically the code coverage metric that we are looking at here) to reject or accept commits in the repository.

When using the code coverage metric you should not just have a fixed (arbitrary) percentage which must be fulfilled. Doing this does not give you the real benefits of code coverage analysis in my opinion. Instead, define the following metrics:

  • Low Water Mark (LWM), the lowest number of uncovered lines ever seen in the system under test
  • High Water Mark (HWM), the highest code coverage percentage ever seen for the system under test

New code can only be added if we don't go above the LWM and we don't go below the HWM. In other words, code coverage is not allowed to decrease, and new code should be covered. Notice how i say should and not must (explained below).

But doesn't this mean that it will be impossible to clean away old well-tested rubbish that you have no use for anymore? Yes, and that's why you have to be pragmatic about these things. There are situations when the rules have to be broken, but for your typical day-to-day integration my experience it that these metrics are quite useful. They give the following two implications.

  • Testable code is promoted. When adding new code you really have to make an effort to make the code testable, because you will have to try and cover all of it with your test cases. Testable code is usually a good thing.

  • Test coverage for legacy code is increasing over time. When adding new code and not being able to cover it with a test case, one can try to cover some legacy code instead to get around the LWM rule. This sometimes necessary cheating at least gives the positive side effect that the coverage of legacy code will increase over time, making the seemingly strict enforcement of these rules quite pragmatic in practice.

And again, if the feedback loop is too long it might be completely unpractical to setup something like this in the integration process.

I would also like to mention two more general benefits of the code coverage metric.

  • Code coverage analysis is part of the dynamic code analysis (as opposed to the static one, i.e. Lint). Problems found during the dynamic code analysis (by tools such as the purify family, http://www-03.ibm.com/software/products/en/rational-purify-family) are things like uninitialized memory reads (UMR), memory leaks, etc. These problems can only be found if the code is covered by an executed test case. The code that is the hardest to cover in a test case is usually the abnormal cases in the system, but if you want the system to fail gracefully (i.e. error trace instead of crash) you might want to put some effort into covering the abnormal cases in the dynamic code analysis as well. With just a little bit of bad luck, a UMR can lead to a segfault or worse.

  • People take pride in keeping 100% for new code, and people discuss testing problems with a similar passion as other implementation problems. How can this function be written in a more testable manner? How would you go about trying to cover this abnormal case, etc.

And a negative, for completeness.

  • In a large project with many involved developers, everyone is not going to be a test-genius for sure. Some people tend to use the code coverage metric as proof that the code is tested and this is very far from the truth, as mentioned in many of the other answers to this question. It is ONE metric that can give you some nice benefits if used properly, but if it is misused it can in fact lead to bad testing. Aside from the very valuable side effects mentioned above a covered line only shows that the system under test can reach that line for some input data and that it can execute without hanging or crashing.

85% would be a good starting place for checkin criteria.

I'd probably chose a variety of higher bars for shipping criteria - depending on the criticality of the subsystems/components being tested.

Many shops don't value tests, so if you are above zero at least there is some appreciation of worth - so arguably non-zero isn't bad as many are still zero.

In the .Net world people often quote 80% as reasonble. But they say this at solution level. I prefer to measure at project level: 30% might be fine for UI project if you've got Selenium, etc or manual tests, 20% for the data layer project might be fine, but 95%+ might be quite achievable for the business rules layer, if not wholly necessary. So the overall coverage may be, say, 60%, but the critical business logic may be much higher.

I've also heard this: aspire to 100% and you'll hit 80%; but aspire to 80% and you'll hit 40%.

Bottom line: Apply the 80:20 rule, and let your app's bug count guide you.

I use cobertura, and whatever the percentage, I would recommend keeping the values in the cobertura-check task up-to-date. At the minimum, keep raising totallinerate and totalbranchrate to just below your current coverage, but never lower those values. Also tie in the Ant build failure property to this task. If the build fails because of lack of coverage, you know someone's added code but hasn't tested it. Example:

<cobertura-check linerate="0"
                 branchrate="0"
                 totallinerate="70"
                 totalbranchrate="90"
                 failureproperty="build.failed" />

When I think my code isn't unit tested enough, and I'm not sure what to test next, I use coverage to help me decide what to test next.

If I increase coverage in a unit test - I know this unit test worth something.

This goes for code that is not covered, 50% covered or 97% covered.

Code coverage is just another metric. In and of itself, it can be very misleading (see www.thoughtworks.com/insights/blog/are-test-coverage-metrics-overrated). Your goal should therefore not be to achieve 100% code coverage but rather to ensure that you test all relevant scenarios of your application.

If you've been doing unit testing for a decent amount of time, I see no reason for it not to be approaching 95%+. However, at a minimum, I've always worked with 80%, even when new to testing.

This number should only include code written in the project (excludes frameworks, plugins, etc.) and maybe even exclude certain classes composed entirely of code written of calls to outside code. This sort of call should be mocked/stubbed.

Generally speaking, from the several engineering excellence best practices papers that I have read, 80% for new code in unit tests is the point that yields the best return. Going above that CC% yields a lower amount of defects for the amount of effort exerted. This is a best practice that is used by many major corporations.

Unfortunately, most of these results are internal to companies, so there are no public literatures that I can point you to.

Code coverage is great but only as long as the benefits that you get from it outweigh the cost/effort of achieving it.

We have been working to a standard of 80% for some time, however we have just made the decison to abandon this and instead be more focused on our testing. Concentrating on the complex business logic etc,

This decision was taken due to the increasing amount of time we spent chasing code coverage and maintaining existing unit tests. We felt we had got to the point where the benefit we were getting from our code coverage was deemed to be less than the effort that we had to put in to achieve it.

I prefer to do BDD, which uses a combination of automated acceptance tests, possibly other integration tests, and unit tests. The question for me is what the target coverage of the automated test suite as a whole should be.

That aside, the answer depends on your methodology, language and testing and coverage tools. When doing TDD in Ruby or Python it's not hard to maintain 100% coverage, and it's well worth doing so. It's much easier to manage 100% coverage than 90-something percent coverage. That is, it's much easier to fill coverage gaps as they appear (and when doing TDD well coverage gaps are rare and usually worth your time) than it is to manage a list of coverage gaps that you haven't gotten around to and miss coverage regressions due to your constant background of uncovered code.

The answer also depends on the history of your project. I've only found the above to be practical in projects managed that way from the start. I've greatly improved the coverage of large legacy projects, and it's been worth doing so, but I've never found it practical to go back and fill every coverage gap, because old untested code is not well understood enough to do so correctly and quickly.

Check out Crap4j. It's a slightly more sophisticated approach than straight code coverage. It combines code coverage measurements with complexity measurements, and then shows you what complex code isn't currently tested.

My answer to this conundrum is to have 100% line coverage of the code you can test and 0% line coverage of the code you can't test.

My current practice in Python is to divide my .py modules into two folders: app1/ and app2/ and when running unit tests calculate the coverage of those two folders and visually check (I must automate this someday) that app1 has 100% coverage and app2 has 0% coverage.

When/if I find that these numbers differ from standard I investigage and alter the design of the code so that coverage conforms to the standard.

This does mean that I can recommend achieving 100% line coverage of library code.

I also occasionally review app2/ to see if I could possible test any code there, and If I can I move it into app1/

Now I'm not too worried about the aggregate coverage because that can vary wildly depending on the size of the project, but generally I've seen 70% to over 90%.

With python, I should be able to devise a smoke test which could automatically run my app while measuring coverage and hopefully gain an aggreagate of 100% when combining the smoke test with unittest figures.

Viewing coverage from another perspective: Well-written code with a clear flow of control is the easiest to cover, the easiest to read, and usually the least buggy code. By writing code with clearness and coverability in mind, and by writing the unit tests in parallel with the code, you get the best results IMHO.

In my opinion, the answer is "It depends on how much time you have". I try to achieve 100% but I don't make a fuss if I don't get it with the time I have.

When I write unit tests, I wear a different hat compared to the hat I wear when developing production code. I think about what the tested code claims to do and what are the situations that can possible break it.

I usually follow the following criteria or rules:

  1. That the Unit Test should be a form of documentation on what's the expected behavior of my codes, ie. the expected output given a certain input and the exceptions it may throw that clients may want to catch (What the users of my code should know?)

  2. That the Unit Test should help me discover the what if conditions that I may not yet have thought of. (How to make my code stable and robust?)

If these two rules doesn't produce 100% coverage then so be it. But once, I have the time, I analyze the uncovered blocks and lines and determine if there are still test cases without unit tests or if the code needs to be refactored to eliminate the unecessary codes.

It depends greatly on your application. For example, some applications consist mostly of GUI code that cannot be unit tested.

I don't think there can be such a B/W rule.
Code should be reviewed, with particular attention to the critical details.
However, if it hasn't been tested, it has a bug!

Short answer: 60-80%

Long answer: I think it totally depends on the nature of your project. I typically start a project by unit testing every practical piece. By the first "release" of the project you should have a pretty good base percentage based on the type of programming you are doing. At that point you can start "enforcing" a minimum code coverage.

Depending on the criticality of the code, anywhere from 75%-85% is a good rule of thumb. Shipping code should definitely be tested more thoroughly than in house utilities, etc.

This has to be dependent on what phase of your application development lifecycle you are in.

If you've been at development for a while and have a lot of implemented code already and are just now realizing that you need to think about code coverage then you have to check your current coverage (if it exists) and then use that baseline to set milestones each sprint (or an average rise over a period of sprints), which means taking on code debt while continuing to deliver end user value (at least in my experience the end user doesn't care one bit if you've increased test coverage if they don't see new features).

Depending on your domain it's not unreasonable to shoot for 95%, but I'd have to say on average your going to be looking at an average case of 85% to 90%.

I think the best symptom of correct code coverage is that amount of concrete problems unit tests help to fix is reasonably corresponds to size of unit tests code you created.

I think that what may matter most is knowing what the coverage trend is over time and understanding the reasons for changes in the trend. Whether you view the changes in the trend as good or bad will depend upon your analysis of the reason.

We were targeting >80% till few days back, But after we used a lot of Generated code, We do not care for %age, but rather make reviewer take a call on the coverage required.

From the Testivus posting I think the answer context should be the second programmer. Having said this from a practical point of view we need parameter / goals to strive for. I consider that this can be "tested" in an Agile process by analyzing the code we have the architecture, functionality (user stories), and then come up with a number. Based on my experience in the Telecom area I would say that 60% is a good value to check.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top