Que peuvent être des métriques alternatives à la couverture de code?

Question

La couverture de code est probablement la métrique de code la plus controversée. Certains disent que vous devez atteindre une couverture de code de 80%, d'autres disent, c'est superficiel et ne dit rien sur la qualité de vos tests. (Voir la bonne réponse de Jon Limjap sur & "Qu'est-ce qu'un pourcentage de couverture de code raisonnable pour les tests unitaires (et pourquoi)? " .)

Les gens ont tendance à tout mesurer. Ils ont besoin de comparaisons, de points de repère, etc.
Les équipes de projet ont besoin d’un pointeur, de la qualité de leurs tests.

Alors, quelles sont les alternatives à la couverture de code? Quelle serait une bonne mesure qui en dit plus que & "J'ai touché cette ligne de code &" ;??
Y a-t-il de vraies alternatives?

Answer 1

Si vous recherchez des statistiques utiles qui vous renseignent sur la qualité (ou le manque de qualité) de votre code, consultez les statistiques suivantes:

1. Complexité cyclomatique
   • Il s'agit d'une mesure de la complexité d'une méthode.
   • Habituellement, 10 et moins c'est bien, 11 à 25 c'est mauvais, plus c'est terrible.
2. Profondeur de nidification
   • Il s'agit d'une mesure du nombre d'étendues imbriquées dans une méthode.
   • Habituellement, 4 et moins est bon, 5-8 est faible, plus élevé est terrible.
3. Cohésion relationnelle
   • Il s'agit d'une mesure de la relation entre les types d'un package ou d'un assemblage.
   • La cohésion relationnelle est un peu une mesure relative, mais néanmoins utile.
   • Les niveaux acceptables dépendent de la formule. Compte tenu de ce qui suit:
     • R: nombre de relations dans le package / assemblage
     • N: nombre de types dans le package / assembly
     • H: Cohésion des relations entre types
   • Formule: H = (R + 1) / N
   • Étant donné la formule ci-dessus, la plage acceptable est comprise entre 1,5 et 4,0
4. Manque de cohésion des méthodes (LCOM)
   • Ceci est une mesure de la cohésion d'une classe.
   • La cohésion d'une classe est une mesure du nombre de champs référencés par chaque méthode.
   • Indication satisfaisante de la conformité de votre classe au principe de responsabilité unique.
   • Formule: LCOM = 1 - (somme (MF) / M * F)
     • M: nombre de méthodes de la classe
     • F: nombre de champs d'instance dans la classe
     • MF: nombre de méthodes de la classe accédant à un champ d'instance particulier
     • sum (MF): la somme de MF sur tous les champs d'instance
   • Une classe totalement cohérente aura un LCOM de 0.
   • Une classe totalement non cohésive aura un LCOM de 1.
   • Plus vous approchez de 0, plus votre classe est cohérente et maintenable.

Ce ne sont là que quelques-unes des mesures clés que NDepend, un utilitaire de mesures et de mappage des dépendances .NET, peut vous fournir. J'ai récemment beaucoup travaillé avec les métriques de code, et ces 4 métriques sont les métriques clés essentielles que nous avons trouvées les plus utiles. Cependant, NDepend propose plusieurs autres mesures utiles, notamment Efferent & Amp; Couplage afférent et abstraitité & Amp; L’instabilité, qui combinée, fournit une bonne mesure de la maintenabilité de votre code (et de ce que NDepend appelle ou non la zone de douleur ou la zone d’inutilité.)

Même si vous ne travaillez pas avec la plate-forme .NET, je vous recommande de consulter la page NDepend. . Il existe de nombreuses informations utiles que vous pourrez peut-être utiliser pour calculer ces métriques sur la plate-forme sur laquelle vous développez.

Answer 2

Crap4j est une métrique assez bonne dont je suis au courant ...

Il s’agit d’une implémentation Java de la métrique logicielle du logiciel Change Risk Analysis and Predictions, qui combine la complexité cyclomatique et la couverture de code issue de tests automatisés.

Answer 3

Les métriques de bogues sont également importantes:

• Nombre de bogues entrant
• Nombre de bugs résolus

Pour détecter, par exemple, si des bogues ne sont pas résolus aussi rapidement que de nouvelles apparitions.

Answer 4

Pourquoi ne pas suivre l'évolution de la couverture de code pendant votre projet?

Comme dans le cas de nombreuses autres mesures, un seul chiffre ne dit pas grand chose.

Par exemple, il est difficile de dire s’il existe un problème si & "; nous avons une conformité aux règles Checkstyle de 78,765432% &"; Si la conformité d'hier était de 100%, nous avons définitivement des problèmes. Si c'était 50% hier, nous ferons probablement du bon travail.

Je suis toujours nerveux quand la couverture de code est devenue de plus en plus basse avec le temps. Il y a des cas où tout va bien, vous ne pouvez donc pas vous arrêter en regardant les tableaux et les chiffres.

BTW, sonar ( http://sonar.codehaus.org/ ) est un excellent outil pour regarder les tendances.

Answer 5

Utiliser la couverture de code seule est généralement inutile, il vous donne un aperçu uniquement si vous recherchez un code inutile.

En l’utilisant avec des tests unitaires et en recherchant une couverture à 100%, vous constaterez que toutes les pièces «testées» (en supposant que tout se passe bien également) fonctionnent comme spécifié dans le test unitaire.

La rédaction de tests unitaires à partir d'une conception technique / fonctionnelle, avec une couverture à 100% et des tests réussis à 100%, vous indiquera que le programme fonctionne comme décrit dans la documentation.

Maintenant, tout ce dont vous avez besoin, c'est d'une bonne documentation, en particulier de la conception fonctionnelle. Un programmeur ne devrait écrire que s'il est un expert de ce domaine spécifique.

Answer 6

La couverture de code est juste un indicateur et permet de mettre en évidence les lignes qui ne sont pas exécutées du tout dans vos tests, ce qui est assez intéressant. Si vous atteignez environ 80% de la couverture de code, il devient logique d'examiner les 20% restants de lignes pour déterminer s'il vous manque un cas d'utilisation. Si vous voyez & "Aha, cette ligne est exécutée si je passe un vecteur vide &"; alors vous pouvez réellement écrire un test qui passe un vecteur vide.

Comme alternative, si vous avez un document de spécifications avec cas d'utilisation et exigences fonctionnelles, vous devez y mapper les tests unitaires et voir combien d'UC sont couvertes par FR (bien sûr, il devrait être de 100%). et combien de FR sont couverts par l’UT (encore une fois, ce devrait être 100%).

Si vous n'avez pas de spécifications, qui s'en soucie? Tout ce qui se passe sera ok:)

Answer 7

Que diriez-vous de (lignes de code) / (nombre de cas de test)? Pas très significatif (car cela dépend du LOC), mais au moins, il est facile à calculer.

Un autre pourrait être (nombre de tests) / (nombre de méthodes).

Answer 8

Couverture de scénario.

Je ne pense pas que vous souhaitiez réellement une couverture de code à 100%. En testant, de simples accesseurs et setters ressemblent à une perte de temps.

Le code s'exécute toujours dans certains contextes. Vous pouvez donc répertorier autant de scénarios que vous le pouvez (en fonction de la complexité du problème, parfois même tous) et les tester.

Exemple:

// parses a line from .ini configuration file
// e.g. in the form of name=value1,value2
List parseConfig(string setting)
{
    (name, values) = split_string_to_name_and_values(setting, '=')
    values_list = split_values(values, ',')
    return values_list
}

Vous avez maintenant plusieurs scénarios à tester. Certains d'entre eux:

• Transmission de la valeur correcte

• Élément de liste

• Passage à null

• Transmission de chaîne vide

• Passage du paramètre mal formaté

• Chaîne de transmission avec une virgule au début ou à la fin, par exemple. nom = valeur1 ou nom = valeur2

Lancer juste le premier test peut vous donner (selon le code) une couverture de code de 100%. Mais vous n'avez pas pris en compte toutes les possibilités, de sorte que la métrique en elle-même ne vous en dit pas beaucoup.

Answer 9

J'ai écrit un billet de blog expliquant pourquoi Le rapport de couverture de test élevé est une bonne chose quand même .

Je conviens que: lorsqu'une partie du code est exécutée par des tests, cela ne & # 8217; t ne signifie pas que la validité des résultats produits par cette partie du code est vérifiée par des tests .

Néanmoins, si vous utilisez fréquemment des contrats pour vérifier la validité des états pendant l'exécution des tests, une couverture de test élevée impliquera néanmoins beaucoup de vérification.

Answer 10

La valeur de la couverture de code est qu'elle vous donne une idée de ce qui a été exercé par les tests. La phrase & "; Couverture de code &"; est souvent utilisé pour désigner une couverture de relevé, par exemple & "Quelle partie de mon code (en lignes) a été exécutée &"; mais il existe en fait plus de cent variétés de & "; couvertures < !> quot. Ces autres versions de couverture tentent de fournir une vue plus sophistiquée de l’exercice du code.

Par exemple, la couverture de conditions mesure le nombre d'éléments distincts d'expressions conditionnelles qui ont été exercés. Ceci est différent de la couverture de relevé. MC / DC " couverture de condition / décision modifiée " détermine si les éléments de toutes les expressions conditionnelles contrôlent tous le résultat de la condition conditionnelle et sont requis par la FAA pour les logiciels de bord. La couverture de chemin mesure le nombre de chemins d’exécution possibles dans votre code qui ont été exercés. Il s'agit d'une meilleure mesure que la couverture d'instructions, dans la mesure où les chemins représentent essentiellement différents cas dans le code. Laquelle de ces mesures est la meilleure à utiliser dépend de votre préoccupation quant à l'efficacité de vos tests.

Wikipedia décrit assez bien de nombreuses variantes de la couverture des tests. http://fr.wikipedia.org/wiki/Code_coverage

Answer 11

En règle générale, les taux d’injection de défauts sont proportionnels au rendement du code et suivent tous deux une courbe de distribution de Rayleigh.
À un moment donné, votre taux de détection des défauts atteindra un pic et commencera ensuite à diminuer.
Cet apex représente 40% des défauts découverts.
À l’avenir, avec une simple analyse de régression, vous pouvez estimer le nombre de défauts qui restent dans votre produit à tout moment après le pic.
Ceci est une composante du modèle de Lawrence Putnam.

Answer 12

Cela n’a pas été mentionné, mais la quantité de modifications apportées à un fichier de code ou de méthode donné (en examinant l’historique de contrôle de version) est intéressante, en particulier lorsque vous créez une suite de tests pour du code mal testé. Concentrez vos tests sur les parties du code que vous modifiez beaucoup. Laissez ceux que vous n'aimez pas pour plus tard.

Méfiez-vous des renversements de cause à effet. Vous éviterez peut-être de changer le code non testé et vous aurez peut-être tendance à modifier davantage le code testé.

Answer 13

SQLite est une bibliothèque extrêmement bien testée , et vous pouvez en extraire toutes sortes de métriques.

  

À partir de la version 3.6.14 (toutes les statistiques du rapport se rapportent à cette version de SQLite), la bibliothèque SQLite est composée d’environ 63,2 KSLOC de code C. (KSLOC signifie des milliers de & "Lignes de code source &" Ou, en d'autres termes, des lignes de code excluant les lignes vierges et les commentaires.) Par comparaison, le projet contient 715 fois plus de code de test et de scripts de test - 45261.5 KSLOC.

En fin de compte, ce qui me semble le plus important, c’est qu’aucune de ces mesures possibles ne semble être aussi importante que la simple déclaration, & "elle répond à toutes les exigences. &"; (Ne perdez donc pas de vue cet objectif en train de l'atteindre.)

Si vous voulez quelque chose pour juger les progrès d'une équipe, vous devez définir des exigences individuelles. Cela vous donne quelque chose à pointer et à dire & "Celui-ci est fait, celui-ci n'est pas &"; Ce n’est pas linéaire (la résolution de chaque exigence nécessitera un travail variable), et le seul moyen de le linéariser est si le problème a déjà été résolu ailleurs (et vous pouvez donc quantifier le travail par exigence).

Answer 14

J'aime les revenus, les chiffres de vente, les bénéfices. Ce sont de très bons indicateurs d’un code base.