2011-07-21 3 views
0

J'essaie de modifier le code source de PartCover pour exclure la couverture par méthode. Cependant, il semble que la logique principale soit dans le code C++. Puisqu'il n'est pas possible d'entrer dans le code cpp pendant le débogage, quelqu'un peut-il me guider quant aux fichiers que je devrais modifier? Je pense qu'il devrait être rules.cpp et instrumentator.cpp ... et quelques refactoring nécessaires dans d'autres fichiers .cpp .h et .cs en raison des changements apportés à ceux-ci. Mais si je me trompe, ou s'il y a d'autres endroits que je devrais aussi regarder, s'il vous plaît faites le moi savoir. Toute autre suggestion serait également appréciée.Exclusion de méthode dans PartCover

Merci,


Merci pour votre réponse. Cependant, en décommentant DebugBreak, le nunit-console-86.exe cesse de fonctionner. J'ai changé la version de NUnit à 2.5.7 pour la faire correspondre avec la version de nunit-framework.dll dans le dossier bin de PartCover, mais le problème existe toujours. Une idée de ce qui pourrait en être la cause?

Nous avons notre propre application de console qui fonctionne sage méthode de vérification de la couverture. Il s'assure que si une nouvelle méthode est ajoutée, ou du code dans des méthodes existantes refactorisées, la couverture doit toujours être au moins supérieure à notre pourcentage décidé. Parfois, il existe des méthodes pour lesquelles les tests ne peuvent pas être effectués complètement pour quelque raison que ce soit. Pour ceux-ci, cela n'a aucun sens d'exclure toute la classe.

+0

Sûrement, cette question serait mieux posée sur GitHub avec les gens de soutien actuels de PartCover –

Répondre

0

Les fichiers que vous avez mentionnés sont probablement les meilleurs endroits dans le code C++ pour appliquer votre filtre supplémentaire. Je suppose que vous avez un moyen d'étendre la syntaxe actuellement utilisée pour inclure et exclure les filtres des modules et des classes.

Vous pouvez déboguer le code si vous supprimez le DebugBreak dans CorProfiler :: Initialize (lorsque vous .NET exécute processus et le profileur est chargé cela vous permettra de joindre un C++ débogueur au profileur)

Puis-je demandez pourquoi vous avez besoin d'exclure des méthodes spécifiques? Je peux voir la nécessité d'exclure des classes, c'est-à-dire des classes de test et d'autres méthodes similaires mais non spécifiques, cela semble être quelque chose qui pourrait être plus facile si nécessaire, en ignorant simplement les résultats dans les rapports.