it-swarm.dev

Quelle est la couverture de code "suffisante"?

Nous commençons une campagne pour la couverture de code ici à mon travail, et cela m'a fait penser ... Quelle est la couverture de code suffisante?

Quand arrivez-vous au point de diminuer les rendements de la couverture du code? Quel est le juste milieu entre une bonne couverture et pas assez? Cela varie-t-il selon le type de projet que vous réalisez (c'est-à-dire WPF, WCF, Mobile, ASP.NET) (Ce sont des classes C # que nous écrivons.)

38
Vaccano

Nous visons au moins 70%. Sur les choses qui sont plus facilement testables (structures de données fonctionnelles, par exemple), nous visons 90% et la plupart des individus visent aussi près de 100% que possible. Sur les choses liées à WPF et autres frameworks qui sont très difficiles à tester, nous obtenons une couverture beaucoup plus faible (à peine 70%).

19
Noah Richards

Je suis d'avis que la couverture du code à elle seule est une mesure médiocre. Il est facile de produire des tonnes de tests inutiles qui couvrent le code, mais ne vérifient pas correctement la sortie, ou ne testent pas les cas Edge, par exemple. Couvrir le code signifie simplement qu'il ne lève pas d'exception, pas qu'il soit juste. Vous avez besoin de tests de qualité - la quantité n'est pas si importante.

55
Fishtoaster

"Assez", c'est quand vous pouvez apporter des modifications à votre code en étant sûr de ne rien casser. Sur certains projets, cela pourrait être 10%, sur d'autres, ce pourrait être 95%.

Ce n'est presque jamais aussi élevé que 100%. Cependant, essayer d'obtenir une couverture de code à 100% peut parfois être un excellent moyen de supprimer la corruption de la base de code. N'oubliez pas qu'il existe deux façons d'augmenter la couverture du code: écrivez plus de tests ou supprimez le code. Si le code n'est pas couvert parce qu'il est difficile à tester, il y a de fortes chances que vous puissiez simplifier ou refactoriser pour le rendre plus facile à tester. S'il est trop obscur pour prendre la peine de tester, il y a généralement de bonnes chances que rien d'autre dans le code ne l'utilise.

38
RevBingo

La couverture du code approche 100% asymptotiquement. Par conséquent, ces 5% restants représentent probablement plus d'efforts qu'ils n'en valent, car vous commencez à obtenir des rendements extrêmement faibles pour l'effort dépensé.

14
Robert Harvey

La couverture est une métrique à surveiller, mais ce ne devrait pas être l'objectif ultime. J'ai vu (et certes écrit!) Beaucoup de code à couverture élevée - couverture à 100% (TDD, bien sûr), pourtant:

  • des bugs se posent encore
  • le design peut encore être médiocre
  • vous pouvez vraiment vous tuer en tirant sur une cible de couverture arbitraire - choisissez vos batailles: p

Il y a un "The Way of Testivus" entrée que je pense approprié de faire référence ici :)

7
H.Y.

Seulement 20% de la plupart des codes s'exécuteront 80% du temps . Une analyse de couverture de code n'est pas très utile à moins qu'elle ne soit associée à un graphique d'appel pour déterminer ce qui doit être testé le plus. Cela vous indique où vos cas Edge sont susceptibles d'être. Vous pouvez proposer 100 tests uniquement pour les cas Edge, qui constituent moins de 5% du code réel.

Assurez-vous donc de couvrir 100% des 20% qui définissent les chemins critiques et au moins 50% du reste (selon le graphique des appels). Cela devrait vous offrir (environ) une couverture totale de 70% à 75%, mais cela varie.

Ne perdez pas de temps à essayer d'obtenir une couverture totale de plus de 70% tout en laissant les cas Edge critiques sans contrôles.

5
Tim Post

Utilisez la couverture comme guide pour indiquer les zones non testées. Plutôt que d'avoir un mandat pour la couverture, il est plus sage de comprendre la raison pour laquelle le code n'est pas couvert. Enregistrer une raison du manque à gagner est une bonne discipline qui permet d'équilibrer les risques.

Parfois, la raison n'est pas souhaitable '', par exemple a manqué de temps ", mais pourrait être OK pour une sortie anticipée. Il est préférable de signaler les zones dans lesquelles vous souhaitez revenir pour une augmentation de la couverture plus tard.

Je travaille sur un logiciel de vol critique où une couverture de déclaration à 100% est considérée comme appropriée pour les systèmes non critiques. Pour les systèmes les plus critiques, nous vérifions la couverture des branches/décisions et utilisons une technique appelée MC/DC qui n'est parfois pas assez stricte.

Nous devons également nous assurer que nous avons également couvert le code objet.

Il s'agit d'un équilibre entre le risque, dans notre cas très élevé, contre la valeur/coût. Un choix éclairé est nécessaire en fonction du risque de manquer un bogue.

4
Mark Fisher

Lorsque vous commencez à envisager des modifications susceptibles d'affecter les performances d'exécution, la sécurité, la flexibilité ou la maintenabilité pour permettre une plus grande couverture de code, il est temps de mettre fin à la quête d'une plus grande couverture de code.

J'ai des projets où ce point est de 0% car la couverture est impossible à calculer sans nuire à la conception et d'autres projets où cela atteint 92%.

Les mesures de couverture de code ne sont utiles que pour indiquer si vous avez peut-être manqué certains tests. Ils ne vous disent rien sur la qualité de vos tests.

3
Bill

J'aime vraiment la réponse de @ RevBingo car il suggère que la lutte vers 100% peut vous faire nettoyer ou supprimer le code inutilisé. Ce que je n'ai pas vu dans les autres réponses, c'est une idée de quand vous avez besoin d'une couverture élevée et quand vous n'en avez pas. J'ai essayé de commencer ça. Je pense que l'ajout de détails à un graphique comme celui-ci serait une poursuite plus utile que la recherche d'un numéro de couverture de test adapté à tous les codes.

100%

Pour une API publique, comme les collections Java.util, qui n'est pas couplée à une base de données et ne retourne pas HTML, je pense que la couverture à 100% est un objectif de départ noble, même si vous vous contentez de 90 à 95% en raison du temps ou autre contraintes. L'augmentation de la couverture des tests une fois la fonctionnalité terminée impose un niveau d'examen plus détaillé que les autres types de révision de code. Si votre API est très populaire, les gens l'utiliseront, la sous-classeront, la désérialiseront, etc. d'une manière inattendue. Vous ne voulez pas que leur première expérience soit de trouver un bug ou une erreur de conception!

90%

Pour le code d'infrastructure d'entreprise, qui prend en charge les structures de données et renvoie les structures de données, 100% est probablement un bon objectif de départ, mais si ce code n'est pas suffisamment public pour inviter à de nombreuses utilisations abusives, peut-être que 85% sont toujours acceptables?

75%

Pour le code qui accepte et renvoie des chaînes, je pense que les tests unitaires sont beaucoup plus fragiles, mais peuvent toujours être utiles dans de nombreuses situations.

50% ou moins

Je déteste écrire des tests pour des fonctions qui retournent du HTML car il est si fragile. Que se passe-t-il si quelqu'un modifie le CSS, le JavaScript ou la totalité du blob HTML et anglais que vous renvoyez n'a aucun sens pour les utilisateurs finaux humains? Si vous pouvez trouver une fonction qui utilise beaucoup de logique métier pour produire un peu de HTML, cela peut valoir la peine d'être testé. Mais la situation inverse ne vaut peut-être pas la peine d'être testée.

Près de 0%

Pour certains codes, la définition de "correct" est "a du sens pour l'utilisateur final". Il existe des tests non traditionnels que vous pouvez effectuer par rapport à ce code, comme la vérification grammaticale automatisée ou la validation HTML de la sortie. J'ai même mis en place des instructions grep pour les petites incohérences auxquelles nous sommes généralement la proie au travail, comme dire "Connexion" lorsque le reste du système l'appelle "Connexion". Cet homme n'est pas strictement un test unitaire, mais un moyen utile de détecter les problèmes sans attendre de sortie spécifique.

Mais en fin de compte, seul un être humain peut juger ce qui est sensible aux humains. Les tests unitaires ne peuvent pas vous y aider. Parfois, il faut plusieurs humains pour juger cela avec précision.

Absolue 0%

C'est une catégorie triste et je me sens moins comme quelqu'un pour l'écrire. Mais dans tout projet suffisamment important, il y a des trous de lapin qui peuvent aspirer des semaines-personnes sans fournir aucun avantage commercial.

J'ai acheté un livre car il prétendait montrer comment se moquer automatiquement des données pour tester Hibernate. Mais il n'a testé que les requêtes Hibernate HQL et SQL. Si vous devez faire beaucoup de HQL et SQL, vous n'obtenez vraiment pas l'avantage d'Hibernate. Il existe une forme de base de données en mémoire Hibernate, mais je n'ai pas investi le temps de comprendre comment l'utiliser efficacement dans les tests. Si je l'avais en cours d'exécution, je voudrais avoir une couverture de test élevée (50% -100%) pour toute logique métier qui calcule des éléments en parcourant un graphique d'objet, ce qui oblige Hibernate à exécuter certaines requêtes. Ma capacité à tester ce code est proche de 0% en ce moment et c'est un problème. J'améliore donc la couverture des tests dans d'autres domaines du projet et j'essaie de préférer les fonctions pures à celles qui accèdent à la base de données, principalement parce qu'il est plus facile d'écrire des tests pour ces fonctions. Pourtant, certaines choses ne peuvent pas ou ne devraient pas être testées.

2
GlenPeterson

Les logiciels critiques pour l'espace nécessitent une couverture de déclaration à 100%.

Au début, cela n'a aucun sens. Tout le monde sait qu'une couverture de test complète ne signifie pas que le code est entièrement testé et qu'il n'est pas si difficile d'obtenir une couverture à 100% sans tester réellement l'application.

Néanmoins, une couverture à 100% est une limite inférieure: bien qu'une couverture à 100% ne soit pas la preuve d'un logiciel sans bogue, il est certain qu'avec une couverture moindre, le code n'est pas entièrement testé et cela est tout simplement inacceptable pour les logiciels critiques.

2
mouviciel

Je pense que cela dépend de la partie de l'application que vous testez. Par exemple. pour la logique métier ou tout composant impliquant des transformations de données complexes, je viserais une couverture de 90% (aussi élevée que possible). J'ai souvent trouvé des bugs petits mais dangereux en testant autant de code que possible. Je préfère trouver de tels bogues pendant les tests plutôt que de les laisser se produire sur le site d'un client un an plus tard. De plus, l'avantage d'une couverture de code élevée est qu'elle empêche les gens de changer trop facilement le code de travail, car les tests doivent être adaptés en conséquence.

D'un autre côté, je pense qu'il y a des composants pour lesquels la couverture de code est moins adaptée. Par exemple, lors du test d'une interface graphique, il faut beaucoup de temps pour écrire un test qui couvre tout le code qui est exécuté en cliquant sur un bouton afin de distribuer l'événement aux bons composants. Je pense que dans ce cas, il est beaucoup plus efficace d'utiliser l'approche traditionnelle consistant à effectuer un test manuel dans lequel vous cliquez simplement sur le bouton et observez le comportement du programme (la bonne boîte de dialogue s'ouvre-t-elle? Le bon outil est-il sélectionné ?).

1
Giorgio

Je n'ai pas cette opinion élevée sur l'utilisation de la couverture de code comme mesure pour savoir quand votre suite de tests a une couverture suffisante.

La raison principale en est que si vous avez un processus où vous écrivez d'abord du code, puis des tests, puis examinez la couverture du code pour découvrir où vous avez manqué un test, alors c'est votre processus qui doit être amélioré. Si vous faites du vrai TDD, alors vous avez une couverture de code à 100% hors de la boîte (certes, il y a quelques trivialités que je ne teste pas). Mais si vous regardez la couverture du code pour savoir quoi tester, vous écrirez probablement les mauvais tests.

Donc, la seule chose que vous pouvez conclure de la couverture du code est que si elle est trop faible, vous n'avez pas assez de tests. Mais s'il est élevé, rien ne garantit que vous ayez tous les bons tests.

0
Pete