MOQ Comment testez-vous des méthodes internes?

Vous pouvez utiliser le Attribut InternalsVissibleto Pour rendre les méthodes visibles à MOQ.

http://GeekSwithblogs.net/mattrobertsblog/archive/2008/12/16/how-to-make-a-quotProtectedQuot-method-available-for-QuotPartialQuot-mocking-and-again. ASPX

Si vous avez beaucoup de code qui n'est pas testé par les méthodes publiques, vous avez probablement du code qui devrait être déplacé vers une autre classe.

Comme indiqué dans une autre réponse, vous pouvez utiliser l'attribut InternalsVissibleto pour cela. Mais cela ne signifie pas que vous devriez le faire.

Votre présomption initiale qu'il est nécessaire de tester la méthode interne est une idée fausse des débutants courants sur les tests d'unités.

accordé, il peut exister des cas où des méthodes privées doivent être testées de manière isolée, mais l'affaire commune 99% est que les méthodes privées sont testées implicitement parce qu'elles font passer les méthodes publiques de leurs tests. Les méthodes publiques appellent les méthodes privées.

Les méthodes privées sont là pour une raison. S'ils n'entraînent pas de comportement externe testable, vous n'en avez pas besoin.

L'un de vos tests publics échoue-t-il si vous ne les supprimez pas? Si oui, alors ils sont déjà testés. Sinon, alors pourquoi avez-vous besoin d'eux? Découvrez ce dont vous avez besoin, puis exprimez cela dans un test contre l'interface publique.

Un avantage principal avec TDD est que votre code devient facile à changer. Si vous commencez à tester les internes, le code devient rigide et difficile à changer.

Il n'y a rien de mal à rendre les internes visibles à d'autres classes pour les tests. Si vous devez tester les internes d'une classe, par tous les moyens. Ce n'est pas parce que les méthodes ne sont pas publiques ne signifie pas que vous devez les ignorer et ne tester que les personnes publiques. Une application bien conçue aura réellement une majorité du code encapsulé dans vos classes de manière à ce qu'ils ne soient pas publics. Ainsi, ignorer les méthodes non publiques de vos tests est une grosse erreur IMHO. L'une des beautés de tests unitaires est que vous testez toutes les parties de votre code, quelle que soit la petite et lorsque vos tests sont allumés à 100%, c'est une hypothèse très raisonnable que lorsque toutes ces pièces sont assemblées, votre L'application fonctionnera correctement pour l'utilisateur final. Bien sûr, vérifiez que cette dernière partie est la suivante: les tests de niveau d'intégration entrent dans une discussion différente. Alors testez !!!

InternalsVissibleto est votre ami pour tester les internes. N'oubliez pas de signer vos assemblées et vous êtes en sécurité.

de mon point de vue moqueur doit être utilisé pour se moquer de ce comportement que nous dépendons de mais qui ne sont pas définis à tester. Par conséquent:

Q: Est-ce que je manque quelque chose? - Non, vous ne manquez rien, le MOQ manque à la capacité de se moquer de comportements privés.

Q: Pouvez-vous tester des méthodes internes à l'aide de MOQ? - Si le résultat du comportement privé est visible publiquement, alors oui, vous pouvez tester la méthode interne, mais ce n'est pas à cause de MOQ que vous pouvez les tester. Je voudrais faire un point ici est que la simulation n'est pas la capacité de tester, mais plutôt de la capacité de comportements similaires que nous ne testons pas mais dépendent de.

C: Un avantage principal avec TDD est que votre code devient facile à changer. Si vous commencez à tester les internes, le code devient rigide et difficile à changer - Je ne suis pas d'accord avec ce commentaire pour 2 raisons principales: 1: Ce n'est pas une idée fausse des débutants, car TDD ne concerne pas seulement la possibilité de coder plus rapidement, mais également de meilleurs codes de qualité. D'où le plus test, nous pouvons faire le meilleur. 2: Il ne rend plus le code plus difficile à modifier si vous pouvez en quelque sorte tester les méthodes internes.