Est-il possible d'obtenir une analyse de couverture de code sur un assemblage interop?

Question

J'ai également posé cette question sur les forums MSDN et je n'ai pas trouvé de solution:

http://forums.microsoft.com/msdn/ShowPost .aspx? PostID = 3686852 & SiteID = 1

Le problème fondamental ici, à mon avis, est qu'un assemblage d'interopérabilité ne contient en réalité aucun IL pouvant être instrumenté (à l'exception peut-être de quelques délégués). Ainsi, bien que je puisse mettre en place un projet test qui utilise la couche d'interopérabilité, je ne peux pas comprendre combien de ces méthodes et propriétés j'appelle réellement.

Le plan B consiste à écrire un générateur de code qui crée une bibliothèque de RCWW (Runtime Callable Wrapper Wrappers) et un instrument servant à la couverture de code.

Modifier: @Franci Penov,

Oui, c’est exactement ce que je veux faire. Les composants COM livrés à nous constituent une bibliothèque d'une douzaine de DLL contenant env. 3000 types. Nous utilisons cette bibliothèque dans notre application et sommes chargés de tester cette couche Interop, car le groupe qui nous fournit les bibliothèques effectue des tests minimaux. La couverture de code nous permettrait de nous assurer que toutes les interfaces et coclasses sont exercées. C'est tout ce que j'essaie de faire. Nous avons des projets de test distincts qui utilisent notre propre code managé.

Oui, dans l’idéal, l’équipe du serveur COM devrait tester et analyser son propre code, mais nous ne vivons pas dans un monde idéal et je dois fournir un produit de qualité en fonction de leur travail. Si peut produire un rapport de test indiquant que j'ai testé 80% de leurs interfaces de code et que 50% de celles-ci ne fonctionnent pas comme annoncé, je peux effectuer les corrections qui s'imposent, et non les problèmes de solution de rechange.

La couche fictive que vous avez mentionnée serait utile, mais n'atteindrait pas l'objectif de tester la couche Interop elle-même, et je ne voudrais certainement pas la conserver à la main - nous sommes à la merci du COM les gars en termes de changements aux interfaces.

Comme je l’ai mentionné ci-dessus, la prochaine étape consiste à générer des wrappers pour les wrappers et des instruments à des fins de test.

Answer 1

Pour répondre à votre question, il n'est pas possible d'instrumenter des assemblages d'interopérabilité pour la couverture de code. Ils ne contiennent que des métadonnées et aucun code exécutable puisque vous vous mentionnez vous-même.

En outre, je ne vois pas l’intérêt d’essayer de coder la couverture de l’assemblage interop. Vous devriez mesurer la couverture de code du code que vous écrivez.

D'après le fil de discussion des forums MDN que vous avez mentionné, il me semble que vous souhaitez réellement mesurer la manière dont votre code utilise le composant COM. Sauf si l'objectif de votre code est d'énumérer et d'appeler explicitement toutes les méthodes et propriétés de l'objet COM, vous n'avez pas besoin de mesurer la couverture de code. Vous avez besoin de tests unitaires / de scénarios pour vous assurer que votre code appelle les bonnes méthodes / propriétés au bon moment.

À mon humble avis, la bonne façon de le faire serait d'écrire une couche fictive pour l'objet COM et de vérifier que vous appelez toutes les méthodes / propriétés comme prévu.

Answer 2

Plan C:

utilisez quelque chose comme Mono.Cecil pour insérer des compteurs d'exécution simples dans l'assemblage d'interopérabilité. Par exemple, consultez cette section de la Faq : " je souhaite ajouter des fonctionnalités de traçage à un assemblage impossible à déboguer, est-il possible d’utiliser Cecil? "