Quel est un pourcentage de couverture de code raisonnable pour les tests unitaires (et pourquoi)?

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

Veuillez expliquer comment vous êtes arrivé à votre réponse (puisque si tout ce que vous faisiez était de choisir un numéro, alors j’aurais pu le faire tout seul)

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

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

    Testivus sur la couverture de test

    Un matin, un programmeur a demandé au grand maître:

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

    Le grand maître a répondu:

    “Ne vous inquiétez pas de la couverture, écrivez simplement de bons tests.”

    Le programmeur sourit, s’inclina et partit.

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

    Le grand maître désigna une casserole d’eau bouillante et dit:

    “Combien de grains de riz devrais-je mettre dans ce pot?”

    Le programmeur, perplexe, a répondu:

    «Comment puis-je vous le dire? Cela dépend du nombre de personnes que vous devez nourrir, de leur appétit, de la nourriture que vous servez, de la quantité de riz disponible, etc.

    “Exactement”, a déclaré le grand maître.

    Le deuxième programmeur sourit, s’inclina et partit.

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

    “Quatre-vingts 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 partit.

    Après cette dernière réponse, un jeune apprenti a approché le grand maître:

    «Grand maître, j’ai entendu aujourd’hui que vous répondiez à la même question sur la couverture du code avec trois réponses différentes. Pourquoi?”

    Le grand maître se leva de sa chaise:

    «Viens prendre du thé avec moi et parlons-en.

    Après avoir rempli leurs tasses de thé vert chaud, le grand 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 pas de tests. Il a un long chemin à parcourir; se concentrer sur la couverture du 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, par contre, a beaucoup d’expérience en programmation et en tests. Quand je lui ai répondu en lui demandant combien de grains de riz je devais mettre dans une casserole, je l’ai aidée à comprendre que la quantité de tests nécessaire dépendait d’un certain nombre de facteurs et qu’elle connaissait mieux ces facteurs que moi. . Il n’y a pas de réponse unique, simple, et elle est assez intelligente pour gérer la vérité et travailler avec ça.

    “Je vois”, a déclaré le jeune apprenti, “mais s’il n’y a pas de réponse simple, alors pourquoi avez-vous répondu au troisième programmeur” Quatre-vingt pour cent et pas moins? ”

    Le grand maître riait si fort et si fort que son ventre, preuve qu’il buvait plus que du thé vert, se laissait tomber.

    “Le troisième programmeur ne veut que des réponses simples – même s’il n’y a pas de réponses simples … et ne les suit pas de toute façon.”

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

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

    • Vous pourriez obtenir un 100% en frappant 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 toujours testé tous vos chemins de code utilisés à 80% / freq. Avoir des tests qui testent chaque “jet ExceptionTypeX” ou un programme de protection défensive similaire que vous avez mis en place est un plaisir de ne pas avoir un “must have”

    Alors faites confiance à vos développeurs et soyez minutieux et couvrez chaque chemin à travers leur code. Soyez pragmatique et ne pas chasser la couverture magique à 100%. Si vous définissez votre code, vous devriez obtenir une couverture de 90% + en bonus. Utilisez la couverture de code pour mettre en évidence les morceaux de code que vous avez manqués (cela ne devrait pas se produire si vous TDD si vous écrivez du code pour effectuer un test. Aucun code ne peut exister sans son test partenaire).

    La couverture du code est excellente, mais la couverture des fonctionnalités est encore meilleure. Je ne crois pas à couvrir chaque ligne que j’écris. Mais je crois en l’écriture d’une couverture de test à 100% de toutes les fonctionnalités que je veux fournir (même pour les fonctionnalités supplémentaires que je suis venu avec moi et qui n’ont pas été discutées lors des réunions).

    Je me fiche de savoir si j’aurais un code qui ne serait pas couvert par les tests, mais je me soucierais de refactoriser mon code et de finir par avoir un comportement différent. Par conséquent, la couverture des fonctionnalités à 100% est ma seule cible.

    La réponse acceptée constitue un bon point – il n’ya pas un seul numéro qui puisse servir de norme pour chaque projet. Il y a des projets qui n’ont simplement pas besoin d’une telle norme. À mon avis, lorsque la réponse acceptée est insuffisante, c’est en décrivant comment on pourrait prendre cette décision pour un projet donné.

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

    Quand définir les exigences de couverture de code

    D’abord, 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 objective est la correction . Pour la plupart des logiciels, nous ne pouvons pas le savoir sur toutes les entrées, nous nous contentons donc de dire que le code est bien testé . Ceci est plus facile à connaître, mais rest une norme subjective: il sera toujours ouvert de débattre si vous l’avez rencontré ou non. Ces débats sont utiles et devraient avoir lieu, mais ils révèlent également des incertitudes.

    La couverture du code est une mesure objective: une fois que vous voyez votre rapport de couverture, il n’y a aucune ambiguïté quant à savoir si les normes ont été respectées sont utiles. Cela prouve-t-il l’exactitude? Pas du tout, mais il a un lien évident avec la qualité du test du code, ce qui est notre meilleur moyen d’accroître la confiance dans son exactitude. La couverture du code est une approximation mesurable des qualités incommensurables dont nous nous soucions.

    Certains cas spécifiques où l’établissement d’une norme empirique pourrait apporter une valeur ajoutée:

    • Pour satisfaire les parties prenantes. Pour de nombreux projets, divers acteurs ont un intérêt pour la qualité des logiciels, qui ne sont peut-être pas impliqués dans le développement quotidien du logiciel (responsables, responsables techniques, etc.). les tests dont nous avons réellement besoin “ne sont pas convaincants: ils doivent soit faire entièrement confiance, soit vérifier avec une surveillance étroite et continue (en supposant qu’ils aient même les connaissances techniques nécessaires).
    • Pour normaliser le comportement de l’équipe. En dehors des parties prenantes, si vous travaillez sur une équipe où plusieurs personnes écrivent du code et des tests, il y a de la place pour l’ambiguïté de ce qui est qualifié de “bien testé”. Est-ce que tous vos collègues ont la même idée de quel niveau de test est suffisant? Probablement pas. Comment conciliez-vous cela? Trouvez une mesure sur laquelle vous pouvez tous vous entendre et acceptez-la comme une approximation raisonnable. Cela est particulièrement utile (mais pas exclusivement) dans les grandes équipes, où les prospects peuvent ne pas avoir un contrôle direct sur les développeurs débutants, par exemple. Les réseaux de confiance sont également importants, mais sans mesures objectives, il est facile pour un comportement de groupe de devenir incohérent, même si tout le monde agit de bonne foi.
    • Pour restr honnête. Même si vous êtes le seul développeur et le seul intervenant pour votre projet, vous pouvez avoir certaines qualités en tête pour le logiciel. Au lieu de procéder à des évaluations subjectives continues sur la qualité du test du logiciel (ce qui demande du travail), vous pouvez utiliser la couverture de code comme une approximation raisonnable et laisser les machines le mesurer pour vous.

    Quelles mésortingques utiliser

    La couverture du code n’est pas une mésortingque unique; Il existe plusieurs manières différentes de mesurer la couverture. La norme sur laquelle vous pouvez définir une norme dépend de ce que vous utilisez pour satisfaire cette norme.

    J’utiliserai deux mesures communes comme exemples d’utilisation des normes:

    • Couverture de déclaration : Quel pourcentage de déclarations a été exécuté lors des tests? Utile pour avoir une idée de la couverture physique de votre code: quelle est la quantité de code que j’ai écrite que j’ai réellement testée?
      • Ce type de couverture prend en charge un argument de correction plus faible, mais est également plus facile à atteindre. Si vous utilisez simplement la couverture de code pour vous assurer que les choses sont testées (et non comme un indicateur de la qualité des tests), la couverture des relevés est probablement suffisante.
    • Couverture de twig : quand il y a une logique de twigment (par exemple, un if ), les deux twigs ont-elles été évaluées? Cela donne une meilleure idée de la couverture logique de votre code: combien de chemins possibles mon code peut-il avoir?
      • Ce type de couverture est un indicateur bien meilleur qu’un programme a été testé sur un ensemble complet d’intrants. Si vous utilisez la couverture de code comme votre meilleure approximation empirique pour la confiance dans l’exactitude, vous devez définir des normes basées sur la couverture de twig ou similaire.

    Il existe de nombreuses autres mesures (la couverture de ligne est similaire à la couverture d’instruction, mais donne des résultats numériques différents pour les instructions multilignes, par exemple; la couverture conditionnelle et la couverture de chemin sont similaires à la couverture de twig, mais reflètent une vue plus détaillée des permutations possibles). 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 nombre?

    J’espère qu’il est clair à ce stade que nous parlons d’une approximation pour commencer, de sorte que tout nombre que nous choisissons sera insortingnsèquement approximatif.

    Quelques chiffres que l’on pourrait choisir:

    • 100% Vous pourriez choisir ceci parce que vous voulez être sûr que tout est testé. Cela ne vous donne aucun aperçu de la qualité des tests, mais vous indique qu’un test de qualité a touché tous les énoncés (ou twigs, etc.). Encore une fois, cela revient 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 prétendre que c’est idiot et que 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 du code peut être améliorée en supprimant également le code non testé.
    • 99% (ou 95%, autres chiffres dans les années 90). Convient dans les cas où vous souhaitez transmettre un niveau de confiance similaire à 100%, mais laissez-vous une marge pour ne pas vous soucier du coin difficile à tester code.
    • 80% J’ai vu ce numéro à quelques resockets et je ne sais pas exactement d’où il vient. Je pense que cela pourrait être un détournement étrange de la règle 80-20; Généralement, l’intention est de montrer que la plupart de votre code est testé. (Oui, 51% serait également “le plus”, mais 80% est le plus représentatif de ce que la plupart des gens entendent le plus.) Ceci est approprié pour les cas intermédiaires où “bien testé” n’est pas une priorité Vous ne voulez pas gaspiller vos efforts sur des tests de faible valeur, mais c’est une priorité suffisante que vous souhaiteriez avoir en place une norme.

    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’accroître la confiance dans la correction, et les chiffres inférieurs à 80% ne sont pas particulièrement inspirants. (Oui, c’est subjectif, mais encore une fois, l’idée est de faire le choix subjectif une fois lorsque 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’exactitude est l’objective. La couverture du code n’est que de l’information. cela peut être pertinent pour d’autres objectives. Par exemple, si vous êtes soucieux de la maintenabilité, vous vous souciez probablement du couplage lâche, ce qui peut être démontré par la testabilité, qui à son tour peut être mesurée (dans certains modes) par une couverture de code. Ainsi, votre norme de couverture de code fournit une base empirique pour évaluer également la qualité de la «maintenabilité».

    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”, je suis fait.

    Le processus sous-jacent est le suivant:

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

    Ainsi, si mes collaborateurs et moi-même ajoutons du nouveau code ou modifions les tests à l’avenir, il existe une ligne claire pour nous indiquer si nous avons manqué quelque chose d’important: la couverture est tombée en dessous de 100%. Cependant, il offre également la possibilité de gérer différentes priorités de test.

    Je voudrais partager un autre anectode sur la couverture de test.

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

    Scott Hanselman a répondu avec des mots de sagesse :

    Est-ce le droit 20%? Est-ce le 20% qui représente le code le plus touché par vos utilisateurs? Vous pouvez append 50 tests supplémentaires et append seulement 2%.

    Encore une fois, cela revient à ma réponse Testivus on Code Coverage . Combien de riz devriez-vous mettre dans le pot? Ça dépend.

    85% serait un bon sharepoint départ pour les critères d’enregistrement.

    J’avais probablement choisi une variété de barres supérieures pour les critères d’expédition – en fonction de la criticité des sous-systèmes / composants testés.

    Si c’était un monde 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 du moins un fac-similé raisonnable de celui-ci), il doit 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 1) sont bien documentées et 2) que les scénarios de test correspondent à la documentation. Si les résultats attendus ne correspondent pas à ceux de la documentation, vous rencontrez un problème dans votre code, votre documentation ou vos scénarios de test. Toutes sont bonnes à examiner.

    Bonne chance!

    Pour un système bien conçu, où les tests unitaires ont conduit le développement depuis le début, je dirais que 85% est un nombre assez faible. Les petites classes conçues pour être testables ne devraient pas être difficiles à couvrir mieux que cela.

    Il est facile de rejeter cette question avec quelque chose comme:

    • Les lignes couvertes ne correspondent pas à la logique testée et il ne faut pas trop lire le pourcentage.

    C’est vrai, mais il y a des points importants à faire sur la couverture du code. Dans mon expérience, cette mésortingque est en fait très utile lorsqu’elle est utilisée correctement. Cela dit, je n’ai pas vu tous les systèmes et je suis sûr qu’il y en a des tonnes où il est difficile de voir une parsing de la couverture du code apportant une réelle valeur ajoutée. Le code peut sembler si différent et la scope du cadre de test disponible peut varier.

    En outre, mon raisonnement concerne principalement les boucles de rétroaction de test assez courtes. Pour le produit que je développe la boucle de rétroaction la plus courte est assez flexible, couvrant tout, des tests de classe à la signalisation inter-processus. Tester un sous-produit livrable prend généralement 5 minutes et pour une boucle de rétroaction aussi courte, il est en effet possible d’utiliser les résultats de test (et plus précisément la mesure de couverture de code que nous examinons ici) pour rejeter ou accepter des validations dans le référentiel.

    Lorsque vous utilisez la mésortingque de couverture du code, vous ne devez pas avoir un pourcentage fixe (arbitraire) à remplir. Cela ne vous donne pas les avantages réels de l’parsing de la couverture du code à mon avis. Définissez plutôt les mésortingques suivantes:

    • Low Water Mark (LWM), le plus petit nombre de lignes découvertes jamais vues dans le système testé
    • High Water Mark (HWM), le pourcentage de couverture de code le plus élevé jamais vu pour le système testé

    Le nouveau code ne peut être ajouté que si nous n’allons pas au-dessus du LWM et que nous n’allons pas au-dessous du HWM. En d’autres termes, la couverture du code ne doit pas diminuer et le nouveau code doit être couvert. Notez comment je dis devrait et ne doit pas (expliqué ci-dessous).

    Mais cela ne signifie-t-il pas qu’il sera impossible de nettoyer de vieilles ordures testées et inutiles? Oui, et c’est pourquoi vous devez être pragmatique à propos de ces choses. Il y a des situations où les règles doivent être rompues, mais pour votre intégration quotidienne typique, l’expérience montre que ces mesures sont très utiles. Ils donnent les deux implications suivantes.

    • Le code testable est promu. Lorsque vous ajoutez un nouveau code, vous devez vraiment faire un effort pour rendre le code testable, car vous devrez essayer de tout couvrir avec vos cas de test. Le code testable est généralement une bonne chose.

    • La couverture de test pour le code hérité augmente avec le temps. Lorsque vous ajoutez un nouveau code et que vous ne parvenez pas à le couvrir avec un scénario de test, vous pouvez essayer de couvrir certains codes hérités pour contourner la règle LWM. Cette sortingche, parfois nécessaire, a au moins l’effet positif que la couverture du code hérité augmentera avec le temps, ce qui rend la mise en application apparemment ssortingcte de ces règles très pragmatique dans la pratique.

    Et encore une fois, si la boucle de rétroaction est trop longue, il serait peut-être impossible de configurer quelque chose comme cela dans le processus d’intégration.

    Je voudrais également mentionner deux avantages plus généraux de l’indicateur de couverture du code.

    • L’parsing de la couverture du code fait partie de l’parsing du code dynamic (par opposition à l’parsing statique, c’est-à-dire Lint). Les problèmes détectés lors de l’parsing du code dynamic (par des outils tels que la famille de purifications, http://www-03.ibm.com/software/products/en/rational-purify-family ) sont des éléments tels que les lectures de mémoire non initialisées (UMR), memory leaks, etc. Ces problèmes ne peuvent être trouvés que si le code est couvert par un cas de test exécuté . Le code le plus difficile à couvrir dans un test élémentaire est généralement le cas anormal du système, mais si vous souhaitez que le système tombe en panne (trace d’erreur plutôt que crash), vous pouvez essayer de couvrir les cas anormaux. dans l’parsing de code dynamic également. Avec un peu de malchance, une UMR peut entraîner un segfault ou pire.

    • Les gens sont fiers de conserver 100% pour le nouveau code, et les gens discutent des problèmes de test avec une passion similaire à celle des autres problèmes de mise en œuvre. Comment cette fonction peut-elle être écrite de manière plus testable? Comment allez-vous essayer de couvrir ce cas anormal, etc.

    Et un négatif, pour être complet.

    • Dans un grand projet avec beaucoup de développeurs impliqués, tout le monde ne va pas être un génie de test à coup sûr. Certaines personnes ont tendance à utiliser la mésortingque de couverture du code comme preuve que le code est testé, ce qui est très loin de la vérité , comme mentionné dans de nombreuses autres réponses à cette question. C’est une mésortingque unique qui peut vous apporter de bons avantages si elle est utilisée correctement, mais si elle est mal utilisée, elle peut en fait conduire à de mauvais tests. Outre les effets secondaires très importants mentionnés ci-dessus, une ligne couverte montre uniquement que le système testé peut atteindre cette ligne pour certaines données d’entrée et qu’il peut s’exécuter sans se bloquer ou se bloquer.

    Beaucoup de magasins n’évaluent pas les tests, donc si vous êtes au-dessus de zéro au moins, il y a une certaine appréciation de la valeur.

    Dans le monde du .Net, les gens citent souvent 80% comme raisonnables. Mais ils le disent au niveau de la solution. Je préfère mesurer au niveau du projet: 30% pourraient convenir aux projets d’interface utilisateur si vous avez des tests Selenium, etc. ou manuels, 20% pour le projet de couche de données pourraient vous convenir, mais 95% + seraient réalisables pour l’entreprise. couche de règles, sinon totalement nécessaire. Ainsi, la couverture globale peut être, par exemple, de 60%, mais la logique métier critique peut être beaucoup plus élevée.

    J’ai aussi entendu ceci: aspirer à 100% et vous atteindrez 80%; mais aspirez à 80% et vous atteindrez 40%.

    Bottom line: Appliquez la règle 80:20 et laissez le nombre de bogues de votre application vous guider.

    J’utilise cobertura, et quel que soit le pourcentage, je vous recommande de garder les valeurs de la tâche cobertura-check à jour. Au minimum, continuez à augmenter votre totalisation et votre totalisation à un niveau juste inférieur à votre couverture actuelle, mais ne jamais baisser ces valeurs. Reliez également la propriété d’échec de compilation Ant à cette tâche. Si la construction échoue à cause d’un manque de couverture, vous connaissez le code ajouté de quelqu’un mais ne l’avez pas testé. Exemple:

      

    Lorsque je pense que mon code n’est pas suffisamment testé sur une unité et que je ne suis pas sûr de ce que je vais tester ensuite, j’utilise la couverture pour m’aider à décider de la prochaine étape.

    Si j’augmente la couverture dans un test unitaire – je sais que ce test unitaire vaut quelque chose.

    Cela vaut pour le code qui n’est pas couvert, couvert à 50% ou couvert à 97%.

    La couverture de code n’est qu’une autre mesure. En soi, cela peut être très trompeur (voir http://www.thoughtworks.com/insights/blog/are-test-coverage-mesortingcs-overrated ). Votre objective ne devrait donc pas être de parvenir à une couverture à 100% du code, mais plutôt de vous assurer de tester tous les scénarios pertinents de votre application.

    Si vous avez effectué des tests unitaires pendant un laps de temps raisonnable, je ne vois aucune raison de ne pas approcher plus de 95%. Cependant, au minimum, j’ai toujours travaillé avec 80%, même lorsque les tests étaient nouveaux.

    Ce numéro ne doit inclure que le code écrit dans le projet (excluant les frameworks, les plugins, etc.) et peut-être même exclure certaines classes composées entièrement de code écrit d’appels au code extérieur. Ce type d’appel doit être simulé / tronqué.

    D’une manière générale, à partir des documents sur les meilleures pratiques en matière d’ingénierie que j’ai lus, 80% pour le nouveau code dans les tests unitaires est le meilleur résultat. Au-delà de ce pourcentage, CC% génère moins de défauts pour la quantité d’effort exercée. C’est une pratique exemplaire utilisée par de nombreuses grandes entresockets.

    Malheureusement, la plupart de ces résultats sont internes aux entresockets, il n’y a donc pas de littérature publique que je puisse vous indiquer.

    La couverture du code est excellente mais seulement tant que les avantages que vous en tirez l’emportent sur les coûts / efforts nécessaires pour y parvenir.

    Nous travaillons à un niveau de 80% depuis un certain temps, mais nous venons de prendre la décision d’abandonner cela et de nous concentrer davantage sur nos tests. Se concentrer sur la logique métier complexe, etc.

    Cette décision a été prise en raison du temps de plus en plus long que nous consacrions à la couverture du code et au maintien des tests unitaires existants. Nous avons eu le sentiment que les avantages de notre couverture de code ont été jugés inférieurs aux efforts que nous avons dû déployer pour y parvenir.

    Découvrez Crap4j . C’est une approche légèrement plus sophistiquée que la couverture du code direct. Il combine des mesures de couverture de code avec des mesures de complexité, puis vous montre quel code complexe n’est pas actuellement testé.

    Ma réponse à cette énigme est d’avoir une couverture de 100% du code que vous pouvez tester et une couverture de 0% du code que vous ne pouvez pas tester.

    Ma pratique actuelle en Python est de diviser mes modules .py en deux dossiers: app1 / et app2 / et lors de l’exécution des tests unitaires, calculer la couverture de ces deux dossiers et vérifier visuellement (je dois automatiser cela) que l’application1 a 100% de couverture. app2 a une couverture de 0%.

    Si / si je trouve que ces numéros diffèrent de la norme, j’examine et modifie la conception du code pour que la couverture soit conforme à la norme.

    Cela signifie que je peux recommander d’atteindre une couverture de 100% du code de la bibliothèque.

    Je passe aussi de temps en temps en revue app2 / pour voir si je pouvais tester n’importe quel code, et si je peux le déplacer dans app1 /

    Maintenant, je ne m’inquiète pas trop de la couverture globale, car celle-ci peut varier énormément en fonction de la taille du projet, mais j’ai généralement vu 70% à plus de 90%.

    Avec python, je devrais être en mesure de concevoir un test de fumée qui pourrait automatiquement exécuter mon application tout en mesurant la couverture et, espérons-le, obtenir un agrégat de 100% en combinant le test de fumée avec les chiffres les plus faibles.

    Voir la couverture d’un autre sharepoint vue: Le code bien écrit, avec un stream de contrôle clair, est le plus facile à couvrir, le plus facile à lire et généralement le code le moins poussé. En écrivant du code avec la clarté et la couvrabilité à l’esprit, et en écrivant les tests unitaires en parallèle avec le code, vous obtenez les meilleurs résultats à mon humble avis.

    À mon avis, la réponse est “Cela dépend de combien de temps vous avez”. J’essaie d’atteindre 100% mais je ne fais pas de bruit si je ne comprends pas le temps dont je dispose.

    Lorsque j’écris des tests unitaires, je porte un chapeau différent de celui que je porte lors du développement du code de production. Je pense à ce que le code testé prétend faire et quelles sont les situations qui peuvent le briser.

    Je suis généralement les critères ou règles suivants:

    1. Que le test unitaire soit une forme de documentation sur le comportement attendu de mes codes, c.-à-d. la sortie attendue compte tenu d’une certaine entrée et des exceptions que les clients peuvent vouloir intercepter (ce que les utilisateurs de mon code doivent savoir?)

    2. Le test unitaire devrait m’aider à découvrir les conditions possibles auxquelles je n’ai peut-être pas encore pensé. (Comment rendre mon code stable et robuste?)

    Si ces deux règles ne produisent pas une couverture de 100%, alors tant pis. Mais une fois, j’ai le temps, j’parsing les lignes et les blocs découverts et détermine s’il existe encore des cas de test sans tests unitaires ou si le code doit être refait pour éliminer les codes inutiles.

    Je préfère faire BDD, qui utilise une combinaison de tests d’acceptation automatisés, éventuellement d’autres tests d’intégration et de tests unitaires. La question pour moi est de savoir quelle devrait être la couverture cible de la suite de tests automatisée dans son ensemble.

    Cela mis à part, la réponse dépend de votre méthodologie, du langage et des outils de test et de couverture. Lorsque vous utilisez TDD dans Ruby ou Python, il n’est pas difficile de maintenir une couverture à 100%, et cela en vaut la peine. Il est beaucoup plus facile de gérer une couverture de 100% que la couverture de 90%. Autrement dit, il est beaucoup plus facile de combler les lacunes de couverture lorsqu’elles apparaissent (et lorsque les écarts de couverture de TDD sont rares, ils valent généralement la peine). régressions dues à votre arrière-plan constant de code non couvert.

    La réponse dépend également de l’historique de votre projet. J’ai seulement trouvé que ce qui précède était pratique dans les projets gérés dès le départ. J’ai considérablement amélioré la couverture des grands projets hérités, et cela en valait la peine, mais je n’ai jamais trouvé pratique de combler tous les écarts de couverture, car les anciens codes non testés ne sont pas assez bien compris pour le faire correctement. rapidement.

    Cela dépend beaucoup de votre application. Par exemple, certaines applications consistent principalement en un code GUI qui ne peut pas être testé par une unité.

    Je ne pense pas qu’il puisse y avoir une telle règle B / W.
    Le code devrait être revu, en accordant une attention particulière aux détails critiques.
    Cependant, s’il n’a pas été testé, il a un bug!

    Réponse courte: 60-80%

    Réponse longue: Je pense que cela dépend totalement de la nature de votre projet. Je commence généralement un projet par unité en testant chaque pièce pratique. Lors de la première “publication” du projet, vous devriez avoir un très bon pourcentage de base basé sur le type de programmation que vous effectuez. Vous pouvez alors commencer à “appliquer” une couverture de code minimale.

    Selon la criticité du code, de 75% à 85% est une bonne règle. Le code d’expédition doit absolument être testé de manière plus approfondie que les utilitaires internes, etc.

    Cela dépend de la phase du cycle de développement de votre application dans laquelle vous vous trouvez.

    Si vous avez été au développement pendant un certain temps et que vous avez déjà beaucoup de code implémenté et que vous réalisez que vous devez penser à la couverture de code, vous devez vérifier votre couverture actuelle (si elle existe) définir des jalons à chaque sprint (ou une augmentation moyenne sur une période de sprints), ce qui signifie prendre des dettes de code tout en continuant à fournir une valeur utilisateur finale (du moins dans mon expérience, l’utilisateur ne se soucie pas du test) couverture s’ils ne voient pas de nouvelles fonctionnalités).

    Selon votre domaine, il n’est pas déraisonnable de viser 95%, mais je dois dire qu’en moyenne, vous allez regarder un cas moyen de 85% à 90%.

    Je pense que le meilleur symptôme d’une couverture correcte du code est que la quantité de problèmes concrets que les tests unitaires aident à résoudre correspond raisonnablement à la taille du code de tests unitaires que vous avez créé.

    Je pense que ce qui compte le plus, c’est de savoir quelle est la tendance à la couverture au fil du temps et de comprendre les raisons des changements dans la tendance. Que vous considériez les changements de tendance comme bons ou mauvais dépendra de votre parsing de la raison.

    Nous visions plus de 80% jusqu’à quelques jours auparavant, mais après avoir utilisé beaucoup de code généré, nous ne nous soucions pas du% âge, mais nous demandons plutôt aux évaluateurs de prendre les mesures nécessaires.

    D’après le post de Testivus, je pense que le contexte de réponse devrait être le deuxième programmeur. Cela dit, d’un sharepoint vue pratique, nous avons besoin de parameters et d’objectives. Je considère que cela peut être “testé” dans un processus Agile en analysant le code que nous avons l’architecture, la fonctionnalité (user stories), puis nous en sortons un numéro. Sur la base de mon expérience dans le secteur des télécommunications, je dirais que 60% est une bonne valeur à vérifier.