Résoudre les problèmes de couverture du code
S’applique à : Visual Studio
L’outil d’analyse de la couverture du code dans Visual Studio collecte des données pour les assemblys natifs et managés ( fichiers.dll ou .exe ). Toutefois, dans certains cas, la fenêtre Résultats de la couverture du code affiche une erreur similaire à « Résultats vides générés : .... ». Cet article vous aide à résoudre les différentes raisons pour lesquelles vous pouvez rencontrer des résultats vides.
Qu’est-ce que vous devriez voir ?
Si vous choisissez une commande Analyser la couverture du code dans le menu Test et si la build et les tests s’exécutent correctement, vous devriez voir une liste de résultats dans la fenêtre Couverture du code . Vous devrez peut-être développer les éléments pour afficher les détails.
Pour plus d’informations, consultez Utiliser la couverture du code pour déterminer la quantité de code testé.
Raisons possibles de l’absence de résultats ou des anciens résultats
Vous n’utilisez pas la bonne édition de Visual Studio
Vous avez besoin de Visual Studio Enterprise.
Aucun test n’a été exécuté
Analyse
Vérifiez votre fenêtre de sortie. Dans la liste déroulante Afficher la sortie à partir de , choisissez Tests. Vérifiez s’il existe des avertissements ou des erreurs enregistrés.
Explication
L’analyse de la couverture du code est effectuée pendant l’exécution des tests. Il inclut uniquement les assemblys chargés en mémoire lorsque les tests s’exécutent. Si aucun des tests n’est exécuté, il n’y a rien à signaler pour la couverture du code.
Solution
Dans Test Explorer, sélectionnez Exécuter tout pour vérifier que les tests s’exécutent correctement. Corrigez les échecs avant d’utiliser Analyser la couverture du code.
Vous examinez un résultat précédent
Lorsque vous modifiez et réexécutez vos tests, un résultat de couverture du code précédent peut toujours être visible, y compris la coloration du code de cette ancienne exécution. Pour résoudre le problème, procédez comme suit :
- Exécutez Analyser la couverture du code.
- Vérifiez que vous avez sélectionné le jeu de résultats le plus récent dans la fenêtre Résultats de la couverture du code .
Les fichiers .pdb (symboles) ne sont pas disponibles
Analyse
Ouvrez le dossier cible de compilation (généralement bin\debug) et vérifiez que pour chaque assembly, il existe un fichier .pdb dans le même répertoire que le fichier.dll ou .exe .
Explication
Le moteur de couverture du code exige que chaque assembly ait son fichier .pdb associé accessible pendant la série de tests. S’il n’existe aucun fichier .pdb pour un assembly particulier, l’assembly n’est pas analysé.
Le fichier .pdb doit être généré à partir de la même build que les fichiers.dll ou .exe .
Solution
Assurez-vous que vos paramètres de build génèrent le fichier .pdb .
Si les fichiers .pdb ne sont pas mis à jour lors de la génération du projet, ouvrez les propriétés du projet, sélectionnez la page Générer , choisissez Avancé, puis inspectez les informations de débogage.
Dans Visual Studio 2022 et versions ultérieures, pour les projets C# ciblant .NET Core ou .NET 5+, ouvrez les propriétés du projet, sélectionnez l’onglet Générer , choisissez Général et inspectez les symboles de débogage.
Pour les projets C++, vérifiez que les fichiers .pdb générés ont des informations de débogage complètes. Ouvrez les propriétés du projet et vérifiez queLe débogage> de l’éditeur> de liensGénérer des informations de débogage est défini sur Générer des informations de débogage optimisées pour le partage et la publication (/DEBUG :FULL) .
Si les fichiers .pdb et .dll ou .exe se trouvent à des emplacements différents, copiez le fichier .pdb dans le même répertoire. Il est également possible de configurer le moteur de couverture du code pour rechercher des fichiers .pdb à un autre emplacement. Pour plus d’informations, consultez Personnaliser l’analyse de la couverture du code.
Un binaire instrumenté ou optimisé est utilisé
Analyse
Déterminez si le fichier binaire a subi une forme d’optimisation avancée telle que l’optimisation guidée par profil ou a été instrumenté par un outil de profilage tel que vsinstr.exe ou vsperfmon.exe.
Explication
Si un assembly a déjà été instrumenté ou optimisé par un autre outil de profilage, l’assembly est omis de l’analyse de la couverture du code. L’analyse de la couverture du code ne peut pas être effectuée sur ces assemblys.
Solution
Désactivez l’optimisation et utilisez une nouvelle build.
Le code n’est pas managé (.NET) ou natif (C++)
Analyse
Déterminez si vous exécutez des tests sur du code managé ou C++.
Explication
L’analyse de la couverture du code dans Visual Studio est disponible uniquement sur le code managé et natif (C++). Si vous utilisez des outils tiers, tout ou partie du code peut s’exécuter sur une autre plateforme.
Solution
Aucun disponible.
Le nom du projet inclut « DataCollector »
Les projets qui utilisent DataCollector dans le nom du projet ne sont pas identifiés par la couverture du code.
L’assembly a été installé par NGen
Analyse
Déterminez si l’assembly est chargé à partir du cache d’images native.
Explication
Pour des raisons de performances, les assemblys d’images natives ne sont pas analysés. Pour plus d’informations, consultez Ngen.exe (Générateur d’images natives).
Solution
Utilisez une version MSIL de l’assembly. Ne le traitez pas avec NGen.
Le fichier .runsettings personnalisé présente des problèmes de syntaxe
Analyse
Si vous utilisez un fichier .runsettings personnalisé, il peut contenir une erreur de syntaxe. La couverture du code n’est pas exécutée et la fenêtre de couverture du code ne s’ouvre pas à la fin de la série de tests ou affiche les anciens résultats.
Explication
Vous pouvez exécuter vos tests unitaires avec un fichier .runsettings personnalisé pour configurer les options de couverture du code. Les options vous permettent d’inclure ou d’exclure des fichiers. Pour plus d’informations, consultez Personnaliser l’analyse de la couverture du code.
Solution
Il existe deux types d’erreurs possibles :
Erreur XML
Ouvrez le fichier .runsettings dans l’éditeur XML de Visual Studio. Recherchez les indications d’erreur.
Erreur d’expression régulière
Chaque chaîne du fichier est une expression régulière. Examinez chacune d’elles pour rechercher les erreurs, et recherchez en particulier :
- Parenthèses incompatibles (...) ou parenthèses sans séquence d’échappement \(...\). Si vous souhaitez faire correspondre une parenthèse dans la chaîne de recherche, vous devez la placer dans une séquence d’échappement. Par exemple, pour faire correspondre une fonction, utilisez :
.*MyFunction\(double\) - Astérisque ou plus au début d’une expression. Pour faire correspondre une chaîne de caractères, utilisez un point suivi d’un astérisque :
.*
- Parenthèses incompatibles (...) ou parenthèses sans séquence d’échappement \(...\). Si vous souhaitez faire correspondre une parenthèse dans la chaîne de recherche, vous devez la placer dans une séquence d’échappement. Par exemple, pour faire correspondre une fonction, utilisez :
Fichier .runsettings personnalisé avec exclusions incorrectes
Analyse
Si vous utilisez un fichier .runsettings personnalisé, assurez-vous qu’il inclut votre assembly.
Explication
Vous pouvez exécuter vos tests unitaires avec un fichier .runsettings personnalisé pour configurer les options de couverture du code. Les options vous permettent d’inclure ou d’exclure des fichiers. Pour plus d’informations, consultez Personnaliser l’analyse de la couverture du code.
Solution
Supprimez tous les Include nœuds du fichier .runsettings , puis supprimez tous les Exclude nœuds. Si cela résout le problème, remettez-les en phases.
Assurez-vous que le nœud DataCollectors spécifie la couverture du code. Comparez-le à l’exemple dans Personnaliser l’analyse de la couverture du code.
Certains codes sont toujours affichés comme non couverts
Le code d’initialisation dans les DLL natives est exécuté avant l’instrumentation
Analyse
Dans le code natif lié statiquement, une partie de la fonction d’initialisation DllMain et du code qu’elle appelle est parfois affichée comme non couverte, même si le code a été exécuté.
Explication
L’outil de couverture du code fonctionne en insérant l’instrumentation dans un assembly juste avant que l’application ne commence à s’exécuter. Dans tout assembly chargé au préalable, le code d’initialisation dans DllMain s’exécute dès le chargement de l’assembly et avant l’exécution de l’application. Ce code semble ne pas être couvert, ce qui s’applique généralement aux assemblys chargés statiquement.
Solution
Aucun.