Qu'est-ce que la couverture du code et comment la mesurez-vous?

Qu'est-ce que la couverture du code et comment la mesurez-vous?

On m'a posé cette question concernant l'automatisation de la couverture du code de test. Il semble que, en dehors des outils automatisés, c'est plus de l'art que de la science. Existe-t-il des exemples concrets d'utilisation de la couverture de code?

La couverture du code est une mesure du nombre de lignes / blocs / arcs de votre code exécutés pendant l'exécution des tests automatisés.

La couverture du code est collectée à l'aide d'un outil spécialisé pour instrumenter les fichiers binaires pour ajouter des appels de suivi et exécuter un ensemble complet de tests automatisés par rapport au produit instrumenté. Un bon outil vous donnera non seulement le pourcentage du code qui est exécuté, mais vous permettra également d'explorer les données et de voir exactement quelles lignes de code ont été exécutées pendant un test particulier.

Notre équipe utilise Magellan - un ensemble interne d'outils de couverture de code. Si vous êtes une boutique .NET, Visual Studio a intégré des outils pour collecter la couverture du code. Vous pouvez également utiliser des outils personnalisés, comme décrit dans cet article .

Si vous êtes un magasin C ++, Intel a des outils qui fonctionnent pour Windows et Linux, bien que je ne les ai pas utilisés. J'ai également entendu parler de l'outil gcov pour GCC, mais je n'en sais rien et je ne peux pas vous donner de lien.

Quant à la façon dont nous l'utilisons - la couverture du code est l'un de nos critères de sortie pour chaque étape. Nous avons en fait trois mesures de couverture de code - la couverture des tests unitaires (de l'équipe de développement), les tests de scénario (de l'équipe de test) et la couverture combinée.

BTW, bien que la couverture du code soit une bonne mesure de la quantité de tests que vous faites, ce n'est pas nécessairement une bonne mesure de la façon dont vous testez votre produit. Il existe d'autres mesures que vous devez utiliser avec la couverture du code pour garantir la qualité.

La couverture du code teste essentiellement la quantité de votre code couverte par les tests. Donc, si vous avez une couverture de code de 90%, cela signifie qu'il y a 10% de code qui n'est pas couvert par les tests. Je sais que vous pensez peut-être que 90% du code est couvert, mais vous devez regarder sous un angle différent. Qu'est-ce qui vous empêche d'obtenir une couverture de code à 100%?

Un bon exemple sera celui-ci:

if(customer.IsOldCustomer()) 
{
}
else 
{
}

Maintenant, dans le code ci-dessus, il y a deux chemins / branches. Si vous frappez toujours la branche "OUI", alors vous ne couvrez pas la partie else et elle sera affichée dans les résultats de la couverture du code. C'est bien parce que maintenant vous savez ce qui n'est pas couvert et vous pouvez écrire un test pour couvrir l'autre partie. S'il n'y avait pas de couverture de code, vous êtes juste assis sur une bombe à retardement pour exploser.

NCover est un bon outil pour mesurer la couverture du code.

N'oubliez pas qu'avoir une «couverture de code à 100%» ne signifie pas que tout est testé complètement - même si cela signifie que chaque ligne de code est testée, cela ne signifie pas qu'ils sont testés dans toutes les situations (courantes).

J'utiliserais la couverture de code pour mettre en évidence des morceaux de code pour lesquels je devrais probablement écrire des tests. Par exemple, si l'outil de couverture de code indique que myImportantFunction () n'est pas exécuté lors de l'exécution de mes tests unitaires actuels, ils devraient probablement être améliorés.

Fondamentalement, une couverture de code à 100% ne signifie pas que votre code est parfait. Utilisez-le comme guide pour rédiger des tests (unitaires) plus complets.

En complément de quelques points à bon nombre des réponses précédentes:

La couverture du code signifie à quel point votre ensemble de tests couvre bien votre code source. c'est-à-dire dans quelle mesure le code source est couvert par l'ensemble des cas de test.

Comme mentionné dans les réponses ci-dessus, il existe différents critères de couverture, comme les chemins, les conditions, les fonctions, les instructions, etc. Mais les critères supplémentaires à couvrir sont

1. Couverture de la condition: toutes les expressions booléennes à évaluer pour vrai et faux.
2. Couverture de la décision: pas seulement les expressions booléennes à évaluer une fois pour vrai et faux, mais pour couvrir tout le corps if-elseif-else ultérieur.
3. Couverture de boucle: signifie que chaque boucle possible a été exécutée une fois, plus d'une fois et zéro fois. De plus, si nous avons une hypothèse sur la limite maximale, alors, si possible, testez les temps limites maximaux et, un de plus que les temps limites maximaux.
4. Couverture d'entrée et de sortie: testez tous les appels possibles et leur valeur de retour.
5. Couverture de la valeur des paramètres (PVC). Pour vérifier si toutes les valeurs possibles d'un paramètre sont testées. Par exemple, une chaîne peut être l'une de celles-ci: a) null, b) vide, c) espace (espace, tabulations, nouvelle ligne), d) chaîne valide, e) chaîne non valide, f) chaîne à un octet, g ) chaîne à deux octets. Le fait de ne pas tester chaque valeur de paramètre possible peut laisser un bogue. Le test d'une seule d'entre elles pourrait entraîner une couverture de code à 100% car chaque ligne est couverte, mais comme une seule des sept options est testée, cela signifie une couverture de seulement 14,2% de la valeur du paramètre.
6. Couverture d'héritage: dans le cas d'une source orientée objet, lors du retour d'un objet dérivé référencé par la classe de base, la couverture à évaluer, si un objet frère est renvoyé, doit être testée.

Remarque: L'analyse de code statique trouvera s'il existe un code inaccessible ou un code suspendu, c'est-à-dire un code non couvert par un autre appel de fonction. Et aussi d'autres couvertures statiques. Même si l'analyse de code statique signale que 100% du code est couvert, elle ne fournit pas de rapports sur votre ensemble de tests si toute la couverture de code possible est testée.

La couverture du code a été bien expliquée dans les réponses précédentes. Il s'agit donc plutôt d'une réponse à la deuxième partie de la question.

Nous avons utilisé trois outils pour déterminer la couverture du code.

1. JTest - un outil propriétaire construit sur JUnit. (Il génère également des tests unitaires.)
2. Cobertura - un outil de couverture de code open source qui peut facilement être couplé avec des tests JUnit pour générer des rapports.
3. Emma - une autre - celle-ci, nous l'avons utilisée dans un but légèrement différent des tests unitaires. Il a été utilisé pour générer des rapports de couverture lorsque les utilisateurs finaux accèdent à l'application Web. Ceci, associé à des outils de test Web (exemple: Canoo), peut vous fournir des rapports de couverture très utiles qui vous indiquent la quantité de code couverte lors de l'utilisation type par l'utilisateur final.

Nous utilisons ces outils pour

• Vérifier que les développeurs ont écrit de bons tests unitaires
• Assurez-vous que tout le code est traversé pendant les tests de boîte noire

La couverture du code est simplement une mesure du code testé. Il existe une variété de critères de couverture qui peuvent être mesurés, mais ce sont généralement les différents chemins, conditions, fonctions et instructions d'un programme qui constituent la couverture totale. La métrique de couverture de code est juste un pourcentage de tests qui exécutent chacun de ces critères de couverture.

En ce qui concerne le suivi de la couverture des tests unitaires sur mes projets, j'utilise des outils d'analyse de code statique pour garder une trace.

Pour Perl, il y a l'excellent module Devel :: Cover que j'utilise régulièrement sur mes modules.

Si la construction et l'installation sont gérées par Module :: Build, vous pouvez simplement exécuter ./Build testcoverpour obtenir un site HTML agréable qui vous indique la couverture par sous-ligne, ligne et condition, avec de belles couleurs, ce qui permet de voir facilement quel chemin de code n'a pas été couvert.

Dans les réponses précédentes, la couverture du code a été bien expliquée. J'ajoute juste quelques connaissances liées aux outils si vous travaillez iOSet aux OSXplates - formes, Xcode fournit la possibilité de tester et de surveiller la couverture du code.

Liens de référence:

https://developer.apple.com/library/archive/documentation/DeveloperTools/Conceptual/testing_with_xcode/chapters/07-code_coverage.html

https://medium.com/zendesk-engineering/code-coverage-and-xcode-6b2fb8756a51

Les deux sont des liens utiles pour apprendre et explorer la couverture du code avec Xcode.

Pour PHP, vous devriez jeter un œil au Github de Sebastian Bergmann

Fournit des fonctionnalités de collecte, de traitement et de rendu pour les informations de couverture de code PHP.

https://github.com/sebastianbergmann/php-code-coverage