Qu'est-ce qu'un pourcentage de couverture de code raisonnable pour les tests unitaires (et pourquoi)?
Si vous deviez imposer un pourcentage de couverture de code minimum pour les tests unitaires, peut-être même comme obligation de vous engager dans un référentiel, de quoi s'agirait-il?
Veuillez expliquer comment vous en êtes arrivé à votre réponse (puisque si vous n'aviez choisi qu'un numéro, j'aurais pu le faire moi-même;)
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&thread=204677
Testivus sur la couverture du test
Tôt 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 répondit:
"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 a pointé une casserole d'eau bouillante et a dit:
"Combien de grains de riz devrais-je mettre dans ce pot?"
Le programmeur, l'air perplexe, répondit:
"Comment puis-je vous dire éventuellement? Cela dépend du nombre de personnes à nourrir, de leur faim, des autres aliments que vous servez, de la quantité de riz disponible, etc.
"Exactement", dit 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 de 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 s'approcha du grand maître:
"Grand maître, aujourd'hui je vous ai entendu répondre à la même question sur la couverture de code avec trois réponses différentes. Pourquoi?"
Le grand maître se leva de sa chaise:
"Viens chercher du thé frais avec moi et laisse-nous en parler."
Après avoir rempli leur tasse de thé vert chaud, le grand maître commença à répondre:
"Le premier programmeur est nouveau et commence tout juste à tester. En ce moment, il a beaucoup de code et pas de test. Il a un long chemin à parcourir; se concentrer 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, possède une grande expérience de la programmation et des tests. Lorsque je lui ai répondu en lui demandant combien de grains de riz je devrais mettre dans un pot, je l'ai aidée à comprendre que le nombre de tests nécessaires dépend d'un certain nombre de facteurs et qu'elle les connaît mieux que moi - c'est son code après tout. . Il n’existe pas de réponse simple et simple, et elle est suffisamment intelligente pour gérer la vérité et travailler avec cela. "
"Je vois," dit le jeune apprenti, "mais s’il n’ya pas de réponse simple, alors pourquoi avez-vous répondu au troisième programmeur" Quatre-vingts pour cent et pas moins "?"
Le grand maître riait si fort et fort que son ventre, preuve qu'il buvait plus que du thé vert, s'effondra de long en large.
"Le troisième programmeur ne veut que des réponses simples - même lorsqu'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 ont fini de boire leur thé dans un silence contemplatif.
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 un 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 'Nice to have' pas un 'must have'
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 son test de 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).
Peu m'importe si j'aurais un code qui n'est pas couvert par les tests, mais je voudrais bien refactoriser mon code et 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 est un bon argument - il n’ya pas un seul chiffre qui puisse avoir un sens en tant que 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 résout pas le problème, c'est de décrire 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 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.
Code de couverture est une mesure objective: une fois que vous avez vu votre rapport de couverture, il n’ya aucune ambiguïté sur le fait de savoir si les normes ont été respectées sont utiles. 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. Pour de nombreux projets, il existe différents acteurs s'intéressant à la qualité logicielle qui peuvent ne pas être impliqués dans le développement quotidien du logiciel (gestionnaires, responsables techniques, etc.). ) Dire "nous allons écrire tous les tests dont nous avons vraiment besoin" n’est pas convaincant: ils doivent soit faire entièrement confiance, soit vérifier avec une surveillance continue et étroite (en supposant même qu’ils possèdent les connaissances techniques pour le faire.) Fournir des normes mesurables et Il est préférable d’expliquer comment ils se rapprochent raisonnablement des objectifs réels.
- Pour normaliser le comportement des équipes. Les parties prenantes mises à part, si vous travaillez dans une équipe où plusieurs personnes écrivent du code et des tests, il y a place à l'ambiguïté pour 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 seul acteur de votre projet, vous pourriez 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 métriques utiliser
La couverture de code n'est pas une métrique unique; Il existe plusieurs façons de mesurer la couverture. Lequel vous pouvez définir une norme dépend de ce que vous utilisez cette norme à satisfaire.
J'utiliserai deux métriques communes à titre d'exemple pour vous aider à définir des normes:
- Couverture des instructions: Quel pourcentage d’instructions ont été exécutées au cours des tests? Utile pour avoir une idée de 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 choses sont testées (et non comme un indicateur de la qualité du test au-delà), la couverture de relevés est probablement suffisante .
- Couverture des branches: Quand il y a une logique de branchement (par exemple une
if), les deux branches ont-elles été évaluées? Cela donne une meilleure idée de couverture logique de votre code: Combien de chemins possibles que mon code peut emprunter ont-ils été testés?- 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 meilleure approximation empirique pour la confiance en l'exactitude, vous devez définir des normes basées sur la couverture de branche ou similaire.
Il existe de nombreux autres paramètres (la couverture par ligne est similaire à la couverture par relevé, mais donne des résultats numériques différents pour les relevés multilignes, par exemple; la couverture conditionnelle et la couverture par chemin sont similaires à la couverture par branche, 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 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 que l'on pourrait 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 connaissez un sous-ensemble de votre code n’a pas été testé.
- Certains diront 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 occasionnellement.
- 80%. J'ai vu ce numéro utilisé plusieurs fois et je ne sais pas exactement d'où il provient. Je pense il pourrait s'agir d'un étrange détournement de la règle des 80-20; généralement, le but ici est de montrer que la plupart de votre code est testé. (Oui, 51% serait aussi "la plupart", mais 80% est plus représentatif de ce que la plupart des gens veulent dire par la plupart.) Ceci est approprié pour le milieu - les cas classiques où "bien testé" n'est pas une priorité élevée (vous ne voulez pas gaspiller des efforts sur des tests de faible valeur), mais est une priorité suffisante 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 pourrait les définir. 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 encore une fois, 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 l'exactitude. 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 é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", j'ai terminé.
Le processus sous-jacent est:
- J'écris mes tests pour exercer toutes les fonctionnalités et les cas Edge auxquels je peux penser (généralement à partir de la documentation).
- Je lance les outils de couverture de code
- J'examine les lignes ou les chemins non couverts et ceux que je considère comme non importants ou inaccessibles (en raison de la programmation défensive), je les marque comme ne comptant pas
- J'écris de nouveaux tests pour couvrir les lignes manquantes et améliorer la documentation si ces cas Edge ne sont pas mentionnés.
Ainsi, si mes collaborateurs et moi-même ajoutons du 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.
Je voudrais partager une autre anectode sur la couverture de test.
Nous avons un projet énorme dans lequel, sur Twitter, j'ai noté que avec 700 tests unitaires, nous n'avons qu'une couverture de code de 20% .
Scott Hanselman répondit par mots de sagesse :
Est-ce le droit 20%? Est-ce que ce sont les 20% qui représentent le code le plus touché par vos utilisateurs? Vous pouvez ajouter 50 tests supplémentaires et seulement 2%.
Encore une fois, cela revient à ma Testivus sur la couverture de code Réponse. Combien de riz devriez-vous mettre dans le pot? Ça dépend.
Pour un système bien conçu, où les tests unitaires ont guidé 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 sont pas égales à 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 de code. D'après mon expérience, cette métrique 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 que l'analyse de la couverture de code ajoute une valeur réelle. Le code peut sembler si différent et la portée de la structure de test disponible peut varier.
De plus, mon raisonnement concerne principalement des boucles de feedback de test assez courtes. Pour le produit que je développe, la boucle de rétroaction la plus courte est assez flexible et couvre tout, des tests de classe à la signalisation interprocessus. Tester un sous-produit livrable prend généralement 5 minutes et pour une boucle de retour aussi courte, il est en effet possible d'utiliser les résultats du test (et plus précisément la mesure de couverture de code que nous examinons ici) pour rejeter ou accepter les validations dans le référentiel.
Lorsque vous utilisez la métrique de couverture de code, vous ne devez pas simplement avoir un pourcentage fixe (arbitraire) qui doit être rempli. Cela ne vous donne pas les avantages réels de analyse de la couverture de code à mon avis. Au lieu de cela, définissez les métriques 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é
Un nouveau code ne peut être ajouté que si nous n'allons pas au-dessus du LWM et si nous n'allons pas au-dessous du HWM. En d'autres termes, la couverture de code ne doit pas diminuer et le nouveau code devrait être couvert. Remarquez comment je dis devrait et ne doit pas (expliqué ci-dessous).
Mais cela ne signifie-t-il pas qu'il sera impossible d'éliminer de vieux déchets bien testés que vous ne servirez plus? Oui, et c'est pourquoi vous devez être pragmatique à propos de ces choses. Il y a des situations où les règles doivent être enfreintes, mais pour votre intégration typique quotidienne, mon expérience montre que ces métriques 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 le rendre testable, car vous devrez essayer de tout couvrir avec vos scénarios de test. Le code testable est généralement une bonne chose.
La couverture de test pour le code existant augmente avec le temps. Lorsque vous ajoutez un nouveau code et que vous ne pouvez pas le couvrir avec un scénario de test, vous pouvez essayer de couvrir du code hérité au lieu de contourner la règle LWM. Cette tricherie parfois nécessaire donne au moins l’effet secondaire positif que la couverture du code existant augmentera avec le temps, rendant l’application apparemment stricte de ces règles assez pragmatique dans la pratique.
Et encore une fois, si la boucle de rétroaction est trop longue, il peut s'avérer totalement irréaliste de configurer quelque chose comme cela dans le processus d'intégration.
Je voudrais également mentionner deux autres avantages généraux de la métrique de couverture de code.
L’analyse de la couverture de code fait partie de l’analyse de code dynamique (par opposition à l’analyse statique, à savoir Lint). Les problèmes rencontrés lors de l'analyse de code dynamique (à l'aide d'outils tels que la famille purify, http://www-03.ibm.com/software/products/en/rational-purify-family ) sont des éléments tels que Lectures de mémoire non initialisées (UMR), fuites de mémoire, etc. Ces problèmes ne peuvent être résolus que si le code est couvert par un scénario de test exécuté . Le code le plus difficile à couvrir dans un scénario de test est généralement le scénario anormal du système, mais si vous souhaitez que le système échoue normalement (c.-à-d. Trace d'erreur au lieu d'un incident), vous voudrez peut-être tenter de couvrir les cas anormaux. dans l'analyse de code dynamique aussi bien. Avec juste un peu de malchance, une UMR peut conduire à une erreur de segmentation ou pire.
Les utilisateurs sont fiers de conserver à 100% le nouveau code et 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 voulez-vous essayer de couvrir ce cas anormal, etc.
Et un négatif, pour être complet.
- Dans un grand projet impliquant de nombreux développeurs impliqués, tout le monde ne sera certainement pas un génie du test. Certaines personnes ont tendance à utiliser la métrique de couverture de code comme preuve que le code est testé et que cela est très éloigné de la vérité , comme mentionné dans de nombreux autres réponses à cette question. C’EST UNE métrique qui peut vous donner quelques avantages Nice s’il est utilisé correctement, mais s’il est mal utilisé, il peut en fait conduire à de mauvais tests. Outre les effets secondaires très précieux mentionnés ci-dessus, une ligne couverte indique 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 interruption ni blocage.
Si ce 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 à la documentation, vous avez un bogue dans votre code, votre documentation ou vos scénarios de test. Ce qui est bon à vérifier.
Bonne chance!
85% serait un bon point de départ pour les critères d'enregistrement.
J'aurais probablement choisi une variété de barres plus hautes pour les critères d'expédition - en fonction de la criticité des sous-systèmes/composants testés.
De nombreux magasins ne valorisent pas les tests. Par conséquent, si vous êtes au-dessus de zéro, au moins, la valeur sera mieux appréciée. On peut donc dire que le non-zéro n'est pas mauvais, car beaucoup restent nuls.
Dans le monde .Net, les gens citent souvent 80% comme raisonnables. Mais ils disent cela au niveau de la solution. Je préfère mesurer au niveau du projet: 30% peut convenir pour un projet d'interface utilisateur si vous avez des tests de sélénium, etc. ou des tests manuels, 20% pour le projet de couche de données peut convenir, mais 95% ou plus peuvent être tout à fait réalisables pour l'entreprise. couche de règles, si pas entièrement nécessaire. La couverture globale peut donc être de 60%, mais la logique métier critique peut être beaucoup plus élevée.
J'ai aussi entendu ceci: aspirez à 100% et vous toucherez 80%; mais aspirez à 80% et vous atteindrez 40%.
Ligne de fond: 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 juste en dessous de votre couverture actuelle, mais jamais diminuez ces valeurs. Liez également la propriété Ant build failure à cette tâche. Si la compilation échoue à cause d'un manque de couverture, vous connaissez le code ajouté à quelqu'un, mais ne l'a pas testé. Exemple:
<cobertura-check linerate="0"
branchrate="0"
totallinerate="70"
totalbranchrate="90"
failureproperty="build.failed" />
Quand je pense que mon code n'est pas suffisamment testé par un test, et que je ne sais pas quoi tester ensuite, j'utilise une couverture pour m'aider à décider quoi tester ensuite.
Si j'augmente la couverture dans un test unitaire - je sais que ce test unitaire vaut quelque chose.
Cela vaut pour le code non couvert, couvert à 50% ou couvert à 97%.
La couverture de code est juste une autre métrique. En soi, cela peut être très trompeur (voir www.thoughtworks.com/insights/blog/are-test-coverage-metrics-overrated ). Votre objectif ne doit donc pas être d'atteindre une couverture de code à 100%, mais plutôt de vous assurer de tester tous les scénarios pertinents de votre application.
Je préfère utiliser BDD, qui combine des tests de réception automatisés, éventuellement d'autres tests d'intégration et des tests unitaires. La question qui se pose à moi est de savoir quelle devrait être la couverture cible de la suite de tests automatisés.
Cela dit, la réponse dépend de votre méthodologie, de votre langue, de vos tests et de vos outils de couverture. Lorsque vous utilisez TDD dans Ruby ou Python, il n’est pas difficile de maintenir une couverture à 100%, et cela en vaut vraiment la peine. Il est beaucoup plus facile de gérer une couverture à 100% qu'une couverture à 90% ou moins. Autrement dit, il est beaucoup plus facile de combler les lacunes de la couverture au fur et à mesure qu'elles apparaissent (et lorsque vous effectuez un traitement TDD, les lacunes de la couverture sont rares et valent généralement votre temps ) qu’il s’agit de gérer une liste de lacunes de couverture que vous n’avez pas encore résolue et de manquer des régressions de couverture en raison de votre historique constant de code non couvert.
La réponse dépend également de l'historique de votre projet. J'ai seulement constaté que ce qui précède était pratique dans les projets ainsi gérés depuis le début. J'ai grandement amélioré la couverture des grands projets hérités, et cela en a valu la peine, mais je n'ai jamais trouvé pratique de revenir en arrière et de combler toutes les lacunes de la couverture, car les anciens codes non testés ne sont pas assez bien compris pour le faire correctement et correctement. rapidement.
En règle générale, parmi les nombreux articles sur les meilleures pratiques d’excellence en ingénierie que j’ai lus, 80% pour le nouveau code dans les tests unitaires est le point qui produit le meilleur rendement. Si vous dépassez ce pourcentage, vous obtiendrez un nombre de défauts inférieur à l’effort fourni. Il s'agit d'une pratique exemplaire utilisée par de nombreuses grandes entreprises.
Malheureusement, la plupart de ces résultats sont internes aux entreprises. Il n’existe donc aucune littérature publique à laquelle je puisse vous renvoyer.
La couverture par code est excellente, mais seulement tant que les avantages que vous en retirez l'emportent sur le coût/les efforts nécessaires pour l'obtenir.
Nous travaillons à une norme de 80% depuis quelque temps déjà, mais nous venons de prendre la décision d'abandonner ce projet 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 passons à rechercher la couverture de code et à maintenir les tests unitaires existants. Nous estimions que nous en étions arrivés au point où l'avantage que nous tirions de la couverture de notre code était jugé inférieur aux efforts que nous devions déployer pour y parvenir.
Si vous effectuez des tests unitaires depuis assez longtemps, je ne vois aucune raison pour que ce ne soit pas proche de 95% ou plus. Cependant, au minimum, j'ai toujours travaillé avec 80%, même si je ne connaissais pas les tests.
Ce numéro ne doit inclure que le code écrit dans le projet (exclut les frameworks, les plugins, etc.) et peut-être même exclure certaines classes entièrement composées de code écrit d'appels à du code extérieur. Ce genre d’appel devrait être moqué/bousillé.
Ma réponse à cette énigme est d’avoir une couverture en ligne de 100% du code que vous pouvez tester et une couverture en ligne de 0% du code que vous ne pouvez pas tester.
Ma pratique actuelle dans Python consiste à diviser mes modules .py en deux dossiers: app1/et app2/et lors de l'exécution de tests unitaires, calcule la couverture de ces deux dossiers et vérifie visuellement (I doit automatise ce jour) que app1 a une couverture de 100% et app2 a une couverture de 0%.
Quand/si je constate que ces chiffres diffèrent de ceux de la norme, j'examine et modifie la conception du code afin que la couverture soit conforme à la norme.
Cela signifie que je peux recommander une couverture de code de bibliothèque de 100%.
J'examine aussi occasionnellement app2/pour voir s'il est possible de tester n'importe quel code là-bas, et si je le peux, je le déplace dans app1 /
Maintenant, je ne m'inquiète pas trop de la couverture globale car elle peut varier énormément en fonction de la taille du projet, mais en général, j'ai 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érer gagner 100% en combinant le test de fumée avec des chiffres sans équivoque.
Départ Crap4j . C'est une approche légèrement plus sophistiquée que la couverture de code simple. Il combine des mesures de couverture de code avec des mesures de complexité et vous indique ensuite quel code complexe n'est pas actuellement testé.
À 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 problèmes si je ne l'obtiens pas avec le temps dont je dispose.
Lorsque j'écris des tests unitaires, je porte un chapeau différent de celui que je porte lors de l'élaboration du code de production. Je pense à ce que le code testé prétend faire et quelles sont les situations qui peuvent le casser.
Je respecte généralement les critères ou règles suivants:
Que le test unitaire soit une forme de documentation sur le comportement attendu de mes codes, c.-à-d. la sortie attendue étant donnée une certaine entrée et les exceptions qu'elle peut générer que les clients peuvent vouloir intercepter (ce que les utilisateurs de mon code doivent savoir?)
Que le test unitaire m'aide à découvrir les conditions éventuelles auxquelles je n'ai pas encore pensé. (Comment rendre mon code stable et robuste?)
Si ces deux règles ne produisent pas une couverture à 100%, alors qu'il en soit ainsi. Mais une fois que j’ai le temps, j’analyse les blocs et les lignes non couverts et détermine s’il existe encore des tests élémentaires sans tests unitaires ou si le code doit être remanié pour éliminer les codes inutiles.
Cela dépend grandement de votre application. Par exemple, certaines applications sont principalement constituées de code d'interface graphique qui ne peuvent pas être testés à l'unité.
Je ne pense pas qu'il puisse y avoir une telle règle noir et blanc.
Le code devrait être revu, en portant une attention particulière aux détails critiques.
Cependant, s'il n'a pas été testé, il y a un bug!
Réponse courte: 60-80%
Réponse longue: Je pense que cela dépend totalement de la nature de votre projet. En général, je commence un projet en testant à l'unité chaque pièce pratique. Lors de la première "publication" du projet, vous devriez avoir un assez bon pourcentage de base en fonction du type de programmation que vous effectuez. À ce stade, vous pouvez commencer à "appliquer" une couverture minimale du code.
En fonction de la criticité du code, une bonne règle empirique est comprise entre 75% et 85%. Le code d’expédition doit définitivement être testé plus minutieusement que les utilitaires internes, etc.
Cela doit dépendre de la phase du cycle de développement de vos applications dans laquelle vous vous trouvez.
Si vous êtes au développement depuis un certain temps et que vous avez déjà beaucoup de code implémenté et que vous venez de réaliser que vous devez penser à la couverture du code, vous devez vérifier votre couverture actuelle (si elle existe), puis utiliser cette référence pour: Fixez des jalons à chaque sprint (ou une augmentation moyenne sur une période de sprints), ce qui signifie que vous contractez une dette de code tout en continuant à fournir de la valeur à l'utilisateur final (du moins, d'après mon expérience, l'utilisateur final s'en fiche un peu si vous avez augmenté le test couverture s'ils ne voient pas de nouvelles fonctionnalités).
Selon votre domaine, il n’est pas déraisonnable de tirer à 95%, mais je dois dire en moyenne que vous envisagez un cas moyen de 85% à 90%.
Je pense que le meilleur symptôme de la couverture de code correcte 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 importe le plus est de savoir quelle est la tendance de 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 positifs ou négatifs dépendra de votre analyse de la raison.
D'après le commentaire de Testivus, je pense que le contexte de réponse devrait être le deuxième programmeur. Ceci dit d’un point de vue pratique, nous devons rechercher des paramètres/objectifs. Je considère que cela peut être "testé" dans un processus Agile en analysant le code dont nous disposons, ainsi que l’architecture, les fonctionnalités (user stories), puis en fournissant un numéro. D'après mon expérience dans le domaine des télécommunications, je dirais que 60% est un bon rapport qualité-prix à vérifier.
Nous visions plus de 80% jusqu'à il y a quelques jours, mais après avoir utilisé beaucoup de code généré, nous ne nous intéressons pas à% age, mais demandons au réviseur de prendre un appel concernant la couverture requise.