Code du minimum acceptable numéros de couverture dans le monde réel [double]

Question

  

Possible en double:    Qu'est-ce qu'une couverture de code raisonnable% pour les tests unitaires (et pourquoi)?

Je suis au milieu de mettre sur pied des lignes directrices autour de la couverture du code de test unitaire et je veux spécifier un numéro qui fait vraiment sens. Il est facile de répéter le mantra à 100% que je vois partout sur l'internet sans tenir compte de l'analyse coûts-avantages et quand la diminution des rendements en fait des ensembles dans.

Je sollicite les commentaires des personnes qui ont effectivement signalé une couverture de code sur la vie réelle, moyen / projets de grande taille. Qu'est-ce que les pourcentages sont-vous voir? Combien est trop? Je veux vraiment un certain équilibre ( en chiffres ) que les développeurs de volonté d'aider à produire du code de qualité Hight. Est une couverture de 65% trop faible pour attendre? 80% trop élevé?

Answer 1

Lorsque vous mélangez la couverture de code avec la complexité cyclomatique, vous pouvez utiliser la CRAP métrique.

De artima.com :

  

Méthode individuelle Interprétation:

     

Bob Evans et je l'ai regardé beaucoup   d'exemples (en utilisant notre code et beaucoup   projets open source) et écouté   beaucoup d'opinions. Après de longs débats,   nous avons décidé d'utiliser un INITIALEMENT CRAP   Score de 30 comme seuil de   crappiness. Ci-dessous un tableau   montre la quantité de couverture de test   nécessaire pour rester en dessous du CRAP   seuil en fonction de la complexité d'un   méthode:

Method’s Cyclomatic Complexity        % of coverage required to be
                                      below CRAPpy threshold
------------------------------        -------------------------------- 
0 – 5                                   0% 
10                                     42% 
15                                     57% 
20                                     71% 
25                                     80% 
30                                    100% 
31+                                   No amount of testing will keep methods    
                                      this complex out of CRAP territory.

Aucun montant de la couverture de code va garantir « un code de haute qualité » par lui seul.

D'après les commentaires ...

Il est certainement trop laxiste pour donner des méthodes simples une passe sur la couverture. Ce que vous trouverez probablement sur l'application du présent code existant est que la couverture du code augmentera à mesure que vous refactorisation ces méthodes laides (couverture de code devrait augmenter sinon vous êtes refactorisation dangereusement).

Les 0-5 sont essentiellement de fruits mûrs et le retour sur investissement est pas terrible. Cela étant dit, ces méthodes sont merveilleux pour l'apprentissage TDD parce qu'ils sont souvent très faciles à tester.

Answer 2

Personnellement, je pencherais pour une couverture de 80%, mais bien sûr, ce n'est que par rapport ... Personnellement, je ne l'ai pas encore ce achive aussi.

À l'heure actuelle, nous avons une couverture très élevée (99%) sur nos classes d'utilité publique, ce qui est bon parce que les insectes là-dedans vous chasser dans votre application entière.

couverture est pour la plupart Mediocre GUIs, parce que les tests d'écriture pour eux est difficile et le temps cher, donc nous laissons souvent pour ouvrir l'interface utilisateur graphique dans les tests unitaires et s'il n'y a pas d'erreur, nous fermons automatiquement.

Answer 3

Je ne pense pas que vous pouvez vraiment avoir une couverture trop de code. Je pense que vous devez déterminer quel code exécute le « cours normal des affaires » dans l'application et ont que complètement couvert. Pour le reste du code qui ne sont pas dans le cours normal des affaires, commencer à tailler au couteau que vers le bas en faisant le plus critiques. entreprise anormale qui est pas très important a un gain faible pour obtenir une bonne couverture de code là-dessus.

Answer 4

La seule réponse correcte est de tester autant que vous pouvez vous permettre. De toute évidence, cela est un axiome à travers tous les projets d'ingénierie.

Au-delà de cela, il est tout subjectif et dépend fortement du projet à portée de main. Par exemple, les systèmes de contrôle de vol met lockheed sur ferions mieux d'être testé plus de 80%, mais 80% peut suffire pour mon interface graphique frontal à une visionneuse XML.

En règle générale, vous décomposez le coût de l'exécution des tests avec votre équipe. Dans le monde de la théorie, il est de coutume d'avoir d'heures à la suite de la question: combien les tests pouvons-nous nous permettre

Après cela, vous examinez vos modules et vous déterminer quelles parties du code ont le plus de temps passé en eux. Chaque module critique doit être couvert une fois. A partir de là, vous donnez un nombre approprié de tests par rapport à la quantité de modules spécifiques du temps sont exécutés. Donc à la fin, il n'y a pas de numéro de disque « X% » est couvert.

John Musa a un livre très intéressant sur le sujet.

Answer 5

Au programme que je suis (~ 500k SLOC), nous utilisons 100%. C'est une exigence de programme pour passer à la prochaine phase de test. Voici les raisons derrière:

1. Le programme est utilisé dans une certaine sécurité des situations critiques, et vous ne veulent tout de conditions nominales à pas testé

2. Si vous ne frappez pas à 100%, vous     soit écrit le code qui n'est pas     nécessaires, et sont par conséquent perdre     l'argent, ou vous ne testez pas votre     hors des chemins nominaux complètement. Voir     # 1.

3. Vos scénarios de tests unitaires devraient     naturellement, vous obtenez près de 100%,     quel que soit le programme réel     couverture de code métrique que vous utilisez.     Si quelqu'un est à 95% sur la base uniquement sur     leurs scénarios nominaux, hors     exigeant 100% ne sont pas onéreux (et,     à nouveau, vous devriez demander pourquoi vous     ne sont pas à 100% alors. Voir # 2.)

Votre kilométrage sera certainement varier. Si vous ne travaillez pas sur une mission / sécurité applications critiques, que vous n'avez probablement pas besoin d'être soucier de votre couverture de code aussi bien - cependant, je dois demander à nouveau: pourquoi vous écrivez du code que vous n » t besoin?

[Modifier]

D'après les commentaires que j'ai reçu ci-dessous, je dois préciser. La ligne directrice du programme est de 100% de couverture de code pour les tests unitaires. Cette exigence de processus de développement peut être levée si, pour une raison technique, une branche de code ne peut pas être atteint (constructeur par défaut protégé qui est jamais appelé, etc.) L'approbation est généralement accordée à partir d'une partie extérieure, indépendante de l'organisation (go go SQA ).

A partir d'un test d'intégration / systèmes, la couverture de code devient sans objet, que vous commencez à regarder la couverture des besoins. C'est une boule de fil différente tout à fait.

La question initiale était à la recherche de situations du monde réel: Je suis d'accord que non (la plupart?) Toutes les situations du monde réel justifieront 100% de couverture de code à un niveau de test unitaire, mais il y a certainement des cas qui le font, et les programmes qui le font. Et il est une habitude de certains développeurs à écrire du code qu'ils ne ont pas besoin, qui se termine ensuite non testé. Cela devient un cauchemar de maintenance, en tant que développeur ce dernier appellera des méthodes qui ont jamais été « signifiait » à utiliser (ou ont été inclus parce que quelqu'un pensait qu'ils étaient une idée « bien »). Tir pour les forces de couverture de 100% vous répondre à la question: « Pourquoi ai-je écrit cela? »

Answer 6

Cela dépend vraiment. Je sais que beaucoup de logiciels qui va de 0%. J'ai beaucoup de logiciels qui a seul% à deux chiffres. La principale question est ce qui est vraiment nécessaire, et je voulais en termes financiers.