Je suis nouveau dans les tests unitaires et je suis en train de voir si je dois commencer à utiliser plus de l '"intérieur" modificateur d'accès. Je sais que si nous utilisons l '"intérieur" et réglez l'assemblée variable 'InternalsVisibleTo', on peut tester les fonctions que nous ne voulons pas de déclarer publique, de l'examen du projet. Cela me fait penser que je dois toujours utiliser l '"intérieur", car au moins, pour chaque projet (devrait?) a c'est propre, le projet de tests. Pouvez-vous les gars me dire pourquoi je ne devrais pas faire cela? Quand dois-je utiliser "privé"?
Réponses
Trop de publicités?
EricSchaefer
Points
7592
Brian Rasmussen
Points
68853
Si vous voulez tester des méthodes privées, jetez un oeil à et dans le `` espace de noms. Ils offrent des wrappers facile à utiliser dans le code de réflexion nécessaire.
Docs : PrivateType, PrivateObject
Jon Skeet
Points
692016
Gardez à l'aide de privé par défaut. Si un membre ne devrait pas être exposé au-delà de ce type, il ne devrait pas être exposé au-delà de ce type, même à l'intérieur du même projet. Cela rend les choses plus sûr et plus propre - lorsque vous utilisez l'objet, c'est plus clair les méthodes qui vous êtes censé être en mesure d'utiliser.
Cela dit, je pense que c'est raisonnable de le faire naturellement-privé méthodes internes à des fins de test, parfois. Je préfère ça à l'aide de la réflexion, qui est refactoring de convivialité.
Une chose à considérer pourrait être un "ForTest" suffixe:
internal void DoThisForTest(string name)
{
DoThis(name);
}
private void DoThis(string name)
{
// Real implementation
}
Puis, lorsque vous êtes à l'aide de la classe au sein du même projet, il est évident (maintenant et dans le futur) que vous ne devrait pas vraiment être en utilisant cette méthode, il est là uniquement pour des fins de test. C'est très orthodoxe, et non pas quelque chose que je fais moi-même, mais c'est au moins le mérite d'être examinée.
Steven Behnke
Points
2149
Vous pouvez utiliser privés, et vous pouvez appeler les méthodes privées avec la réflexion. Si vous utilisez Visual Studio Team Suite, il a quelques belles fonctionnalité qui permettra de générer un proxy pour appeler les méthodes privées pour vous. Voici un projet de code de l'article qui montre comment vous pouvez faire le travail vous-même à l'unité de test privé et protégé méthodes:
http://www.codeproject.com/KB/cs/testnonpublicmembers.aspx
En termes de modificateur d'accès, vous devez utiliser, mon général, la règle de base est de commencer avec la vie privée et de dégénérer en tant que de besoin. De cette façon, vous exposer que peu de détails internes de votre classe sont vraiment nécessaires et il contribue à la mise en œuvre des détails cachés, comme ils devraient l'être.
En théorie, vous devriez seulement besoin de tester vos méthodes publiques de toute façon. Juste avoir assez de tests que vous êtes en contrôle de tous les chemins de code. En réalité, vous pouvez vérifier quelque chose fonctionne comme prévu à l'avant de l'appeler avec un ensemble beaucoup plus de code.
Si vous utilisez TDD (Test Driven Development) ce n'est généralement pas un problème, car aucun code n'est écrit sans un essai, pas de chemin de code devrait pas encore connu. Interne, privé et protégé méthodes sont alors engendré comme vous refactoriser contre les tests existants.
Le problème vient quand vous n'utilisez pas de TDD et pour s'adapter à des tests dans le code déjà écrit. Ensuite, vous pouvez tester les différents modes sans les rendre publics.
Il y a plusieurs façons que vous pouvez faire. VS2008 propose un assistant pour générer interne accesseurs qui vous pouvez utiliser pour tester des méthodes internes. Ou vous pouvez rouler votre propre en utilisant protégé (pas de méthodes privées) et à l'héritage.
