Pour accueillir des tests unitaires et moqueurs, il est devenu une pratique courante pour déclarer des méthodes et des propriétés comme virtuelle. Existe-t-il un impact sur la performance de déclarer quelque chose de virtuel comme censé non-virtuel?
3 Réponses :
Nope, pas vraiment.
Ce n'est pas quelque chose que vous allez remarquer.
En général, la différence est que les méthodes virtuelles sont appelées à l'aide d'un opcode de CallVirt, tandis que les méthodes virtuelles n'utilisent pas un opcode d'appel standard. Les opcodes d'appel sont définitivement plus rapides que Callvirt, mais je ne les ai jamais trouvées presque suffisamment substantielles pour justifier de prendre des décisions de conception basées sur cela.
L'optimisation prématurée est la racine de tout mal.
IIRC, le compilateur C # utilisera CallVirt pour toutes les méthodes d'instance, qu'elles soient virtuelles. De cette façon, le CLR fait la vérification de la nullité.
@Johnskeet Alors cela signifie-t-il qu'à la fin de la journée, il n'y a vraiment aucune différence?
Bon point John - Vous avez raison à l'exception des méthodes d'instance de type de valeur que je pense - pour lesquelles le compilateur émet un opcodes.call.
Je ne connais pas les détails, mais je sais que vous n'avez pas à vous en soucier de 99% des applications.
BTW - Si vous choisissez de simuler des interfaces au lieu de classes, vous n'avez pas besoin de méthodes virtuelles.
bonne chance, Tom
Vous avez la même «pénalité» indirecte avec une interface comme méthode virtuelle.
Vous pensez conception pour la testabilité consiste simplement à faire tout ce que
virtuel et toutes les classesOuvrir ? Hmm...@Stefanhanke: Je ne vois rien de suggérer que l'Op pense que c'est juste ça.
Ouais je ne pense pas que cela devrait être fait quand ce n'est pas nécessaire ... c'est juste une mesure qui peut améliorer la qualification le cas échéant
@Jonskeet Je faisais référence au terme pratique commune , mais vous avez raison, ma déclaration est trop générale. @TGH Nous avons eu une discussion si tout Adaption de code de production à un cadre de test spécifique est significatif. Par exemple, passez à partir de
Rhino Mocks surMoq (qui utilise une technique différente, plus "puissante") signifie que vous pouvez intercepter tout appel du tout, même des appels de fonction statiques. Nous avons conclu de ne pas le faire du tout et essayez plutôt de concevoir différemment pour faciliter les tests.Je suis en fait très surpris que Moles ne semble pas être plus populaire. Il semble avoir tellement d'avantages sur le MOQ, etc. Vous pouvez essentiellement se moquer de quelque chose dans les moles (même des méthodes privées), il semble que MOQ s'appuie toujours sur des interfaces et des virtuelles.
Oups, désolé,
MOQ utilise des proxies dynamiques également (ne l'utilisez pas). Je voulais dire ceux qui interceptent via l'interface du profileur.@ Des taupes serait populaire mais elle n'est pas facilement soutenue pour le moment, semble-t-il. Allez sur leur site, il a récemment été "éteint"