Question

Arrière-plan

J'ai une application écrite en C ++ natif sur plusieurs années qui tourne autour de 60 KLOC. Il y a beaucoup de fonctions et de classes qui sont mortes (probablement 10 à 15% comme la question similaire basée sur Unix ci-dessous). Nous avons récemment commencé à faire des tests unitaires sur tous les nouveaux codes et à les appliquer au code modifié chaque fois que possible. Cependant, je dirais à SWAG que notre couverture de tests est inférieure à 5% à l'heure actuelle.

Hypothèses / contraintes

La méthode et / ou les outils doivent prendre en charge:

  • C ++ natif (c.-à-d. non géré)
  • Windows XP
  • Visual Studio 2005
  • Ne doit pas exiger de scénario de test fourni par l'utilisateur pour la couverture. (par exemple, ne pouvez pas compter sur les tests unitaires pour générer une couverture de code)

Si les méthodes prennent en charge plus que ces exigences, alors tant mieux.

REMARQUE: nous utilisons actuellement l'édition Professional de Visual Studio 2005, et non Team System. Par conséquent, utiliser Team System peut constituer une suggestion valide (je ne sais pas, je ne l’ai jamais utilisée), mais j’espère que ce n’est pas la solution seulement .

Pourquoi l'utilisation de tests unitaires pour la couverture de code est problématique

Je pense qu’il est impossible pour un outil générique de rechercher tous les morts (par exemple, du code inaccessible) dans une application arbitraire avec zéro faux positif (je pense que cela équivaudrait au problème de Halting). Toutefois, j’estime également qu’un outil générique peut rechercher de nombreux types de code mort qui sont très susceptibles d’être réellement morts, comme des classes ou des fonctions qui ne sont jamais référencées dans le code.

En utilisant des tests unitaires pour fournir cette couverture, vous n’utilisez plus d’algorithme générique et vous augmentez ainsi le pourcentage de code mort que vous pouvez détecter et la probabilité que les hits ne soient pas de faux positifs. À l’inverse, l’utilisation de tests unitaires pourrait donner de faux négatifs, car les tests unitaires eux-mêmes pourraient être la seule opération permettant d’exercer une partie de code donnée. Dans l’idéal, les tests de régression devraient permettre d’exercer toutes les méthodes, API, contrôles utilisateur, etc. disponibles en externe, qui serviraient de mesure de base pour l’analyse de couverture de code afin d’exclure certaines méthodes des faux positifs. Malheureusement, je n'ai pas ce test automatisé à l'heure actuelle.

Depuis que j'ai une base de code aussi volumineuse avec un pourcentage de couverture de cas de test aussi bas, je recherche cependant quelque chose qui puisse aider sans nécessiter beaucoup de temps pour la rédaction de cas de test.

Question

Comment détectez-vous le code mort de manière automatisée ou semi-automatisée dans une application C ++ native sur la plate-forme Windows avec l'environnement de développement Visual Studio 2005?

Voir aussi

Détection de code mort dans un projet hérité C / C ++ je veux dire au VC ++ Compiler pour compiler tout le code. Est-ce possible?

Était-ce utile?

La solution

Demandez à l'éditeur de liens de supprimer les objets non référencés (/ OPT: REF). Si vous utilisez une liaison au niveau de la fonction et une sortie de l'éditeur de liens détaillée, la sortie de l'éditeur de liens répertorie toutes les fonctions qu'il peut prouver comme étant inutilisées. Cette liste est peut-être loin d’être complète, mais vous disposez déjà des outils nécessaires.

Autres conseils

Nous utilisons Bullseye , et je peux le recommander. Il n’a pas besoin d’être exécuté à partir d’un environnement de test unitaire, bien que ce soit ce que nous faisons.

Utilisez un outil de couverture de code par rapport à votre suite de tests unitaires.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top