Comment fonctionnent les outils de couverture de code?

Comment les outils de couverture de code comme NCover savent-ils quelles parties du code ont été exécutées et quelles parties ne l’ont pas été?

Voici un document technique sur la mise en œuvre d’outils de couverture de test pour les langages arbitraires .

Mon entreprise construit une famille d’outils de couverture de test pour Java, C #, C ++, PHP, COBOL, PLSQL, … basée sur ce principe.

Citation tirée de la FAQ NCover: NCover rapporte le pourcentage de twigs dans le code qui ont été sockets au cours de vos tests automatisés. Cela se fait en instrumentant le code source de chaque twig et en écrivant les points “hit” dans un fichier. Ces points sont ensuite comparés au total des points possibles qui pourraient avoir été touchés.

Je sais que cette question est ancienne, mais si vous êtes toujours intéressé, vous pouvez voir un exemple de la façon dont une telle instrumentation est exécutée pour les applications .NET en consultant le projet open source OpenCover .

OpenCover insère des points d’instrumentation à des points significatifs du code.

  1. Pour la couverture de ligne de code, il utilise les points de séquence extraits d’un fichier PDB
  2. Pour la couverture de twig, elle instruit les instructions COND_BRANCH en instrumentant la ou les cibles de saut et l’instruction suivante après l’instruction de twigment, c’est-à-dire sans saut.
  3. Pour l’instrumentation de la méthode, il instruit la première instruction de n’importe quelle méthode.

Toutes ces règles sont appliquées dans CoverageInstrumentation.cpp après que les points appropriés aient été localisés à l’aide de Mono.Cecil et transmis au profileur à partir de l’hôte de la console.

Le code source de PartCover est également disponible (comme indiqué), mais il est beaucoup plus difficile à suivre, mais il utilise également des points de séquence des PDB pour déterminer où il code le code.

De cette source:

NCover utilise l’API de profileur .NET Framework pour surveiller l’exécution d’une application. Lorsqu’une méthode est chargée par le CLR, NCover récupère l’IL et le remplace par un code IL instrumenté.

Donc, en bref, il se connecte à la compilation juste à temps.

Tous les outils ne fonctionnent pas de la même manière. Les autres outils fonctionnent en modifiant le bytecode de votre application après la compilation du code.

Cela nécessite que vous exécutiez vos tests une fois avec l’parsing de couverture de code activée, puis que vous comptiez simplement le nombre de blocs (c’est-à-dire les blocs d’étendue) couverts et les compare au nombre total de blocs du projet que vous testez.

Le raisonnement de base est que si chaque combinaison possible de blocs de code est couverte, tous les chemins de code sont couverts 1 . L’argument principal contre le fait de mettre trop de poids dans les numéros de couverture de code est que les blocs “faciles” comme les getters et les setters, qui ne donnent aucune valeur réelle .


1) Comme indiqué par Ira Baxter dans un commentaire, le libellé précédent de cette phrase était incorrect. Veuillez lire les commentaires pour une discussion à ce sujet.