Moq comment testez-vous les méthodes internes?

Vous pouvez utiliser l’atsortingbut InternalsVisibleTo pour rendre les méthodes visibles par Moq.

http://geekswithblogs.net/MattRobertsBlog/archive/2008/12/16/how-to-make-a-quotprotectedquot-method-available-for-quotpartialquot-mocking-and-again.aspx

Il n’y a rien de mal à rendre les internes visibles aux autres classes pour les tests. Si vous devez tester les éléments internes d’une classe, faites-le absolument. Ce n’est pas parce que les méthodes ne sont pas publiques que vous devez les ignorer et ne tester que les méthodes publiques. Une application bien conçue aura en réalité une majorité du code encapsulé dans vos classes de manière à ce qu’elles ne soient pas publiques. Donc, ignorer les méthodes non publiques dans vos tests est une grosse erreur à mon humble avis. L’un des avantages des tests unitaires est que vous testez toutes les parties de votre code, quelle que soit leur taille. Lorsque vos tests sont opérationnels à 100%, il est tout à fait raisonnable de penser que, lorsque toutes ces parties sont assemblées, l’application fonctionnera correctement pour l’utilisateur final. Bien sûr, la vérification de cette dernière partie est l’endroit où les tests de niveau d’intégration entrent – ce qui est une discussion différente. Alors testez !!!

Si de nombreux codes n’ont pas été testés par les méthodes publiques, vous devez probablement les transférer dans une autre classe.

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

De mon sharepoint vue, Mocking devrait être utilisé pour simuler un comportement sur lequel nous sums dépendants mais que nous ne sums pas sur le sharepoint tester. Par conséquent:

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

Q: Pouvez-vous tester des méthodes internes en utilisant Moq? – Si le résultat du comportement privé est visible publiquement, alors vous pouvez tester la méthode interne, mais ce n’est pas à cause de Moq que vous pouvez les tester. Je voudrais souligner ici que Mock n’est pas la capacité de tester, mais plutôt la capacité de comportements similaires que nous ne testons pas mais sur lesquels nous dépendons.

C: Un des principaux avantages de TDD est que votre code devient facilement modifiable. Si vous commencez à tester les composants internes, le code devient rigide et difficile à modifier. Je ne souscris pas à ce commentaire pour deux raisons principales: aussi un code de meilleure qualité. Par conséquent, plus nous pouvons faire le test, mieux ce sera. 2: Cela ne rend pas le code plus difficile à modifier si vous pouvez en quelque sorte tester les méthodes internes.

Votre présomption initiale selon laquelle il est nécessaire de tester la méthode interne est une idée fausse commune aux débutants sur les tests unitaires.

Certes, il peut exister des cas dans lesquels les méthodes privées doivent être testées séparément, mais dans 99% des cas, les méthodes privées sont testées de manière implicite, car elles permettent aux méthodes publiques de réussir 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 testable externe, vous n’en avez pas besoin.

Est-ce que certains de vos tests publics échouent si vous les supprimez à plat? Si oui, alors ils sont déjà testés. Si non, alors pourquoi en avez-vous besoin? Découvrez ce dont vous avez besoin et exprimez-le dans un test avec l’interface publique.

Le principal avantage de TDD est que votre code devient facilement modifiable. Si vous commencez à tester les composants internes, le code devient rigide et difficile à modifier.

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