C# “interne” modificateur d'accès lorsque vous faites des tests unitaires

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é"?

  • La peine de mentionner - vous pouvez souvent éviter la nécessité pour les tests unitaires de vos méthodes internes en utilisant System.Diagnostics.Debug.Assert() dans les méthodes elles-mêmes.
InformationsquelleAutor Hertanto Lie | 2008-12-11
  1. 1076

    Classes internes doivent être testés et il y a une assemblée de l'attribut:

    using System.Runtime.CompilerServices;

[assembly:InternalsVisibleTo("MyTests")]

    Ajoutez à cela le projet info fichier, par exemple Properties\AssemblyInfo.cs.

    • Dois-je ajouter à l'épreuve de projet ou le projet en cours de test !?!?
    • L'ajouter au projet en cours de test (par exemple dans les Propriétés\AssemblyInfo.cs). "MyTests" serait le montage d'essai.
    • Cela devrait vraiment être la accepté de répondre. Je ne sais pas pour vous les gars, mais lorsque les tests sont "trop loin" dans le code, ils ont testé, j'ai tendance à m'énerver. Je suis tout à fait pour éviter de tester quelque chose de marqué comme private, mais trop de private les choses pourraient très bien point à un internal classe qui a de la difficulté à extraire. TDD ou pas de TDD, je préfère avoir plus de tests que tester un grand nombre de code, plutôt que d'avoir les quelques test que l'exercice de la même quantité de code. Et en évitant de test internal stuff n'est pas exactement aider à obtenir un bon ratio.
    • Merci Eric. Été à la recherche pour que l'option tous les jours.
    • J'ai enveloppé cet attribut avec et #si la LIBÉRATION directive de l'intérieur ne serait pas visible à quoi que ce soit dans un communiqué de construire. Juste une pensée.
    • Tout à fait d'accord...en Plus, il est à peu près impossible à test code de l'INTERFACE utilisateur, j'ai donc généralement différer beaucoup de mes personnalisé à la disposition de l'INTERFACE utilisateur logique dans les méthodes que je peux tester sans nécessairement l'exécution d'un WPF ou WinForms de l'application et de voir le résultat (c'est à dire la commande des éléments, la vérification des informations de position, etc...etc...) Cette logique est certainement marqué internes et absolument pas être testé par le biais de "public" signifie...je ne peux pas supporter quand les gens se rapportent "public" à "testable", ils sont pas de l'une et la même pour tous les cas...et je suis un avocat pour le TDD...
    • Il y a un grand discussion entre @DerickBailey et Dan Tao concernant la différence sémantique entre interne et privé et de la nécessité de tester interne composants. Bien la peine de le lire.
    • Emballage et #if DEBUG, #endif bloc activez cette option uniquement dans les versions de débogage.
    • Où je dois ajouter Interne Visible ? Projet principal ou de projet de test AssemblyInfo classe.
    • Comme déjà dit dans l'autre commentaire: Dans le projet que vous souhaitez tester.
    • Est-ce à dire que vous n'avez pas exécuter des tests unitaires à l'encontre d'un communiqué de construire? Nous exécuter des tests unitaires à la fois pour le debug et release. Les Devs exécuter le débogage de construit de tests unitaires localement, serveur de build fonctionne pour les versions release. Fait en sorte de nous rattraper les différences entre debug et release code causés par les différents paramètres de compilation pour les deux (optimisation par exemple).
    • C'est un bon point et oui j'ai changé ma façon de faire, j'ai tester les versions release, puis commentez les InternalsVisibleTo code pour un déploiement de construire. Si vous commettez le code et le tag à ce point, vous gardez votre étape pour que le déploiement, puis rétablir le code commenté et de poursuivre. Théoriquement, il pourrait y avoir des effets secondaires à cela, mais c'est mieux que pas de test de code de Libération et de livraison code avec un risque de sécurité.
    • Cool. Est InternalsVisibleTo un trou de sécurité, car toute l'assemblée avec le nom spécifié aurait accès à l'intérieur? Je figure que .Net est en soi tellement précaire - à cause de la réflexion et de tous les (IL) désassembleurs, il ne que je ne voudrais pas dépenser l'effort de le retirer pour une version release... Suis-je manqué quelque chose?
    • Oui, à moins de Nom à signer les Assemblées et inclure la clé dans le InternalsVisibleTo attribut. Voir adelkhalil.bloggingabout.net/2007/10/12/... Cela dépend de votre niveau de paranoïa, je suppose.
    • Ah. ok. merci pour le lien. la lecture...
    • C'est la réponse correcte. Toute réponse qui dit que seules les méthodes publiques devrait être l'objet de tests unitaires manque le point de tests unitaires et de faire une excuse. Le test fonctionnel est la boîte noire orientée. Les tests unitaires sont en boîte blanche orientée. Ils devraient tester des "parts" de la fonctionnalité, et non seulement les Api.
    • Pour .NET de Base - ajouter à tout .cs fichier dans l'application. Voir les détails ici - stackoverflow.com/a/42235577/968003
    • Alex Klaus ajouter que comme une réponse. Je viens de passer un certain temps à creuser pour que. .NET de Base est assez nouveau la question a besoin d'une nouvelle réponse.
    • Excellente solution pour les internes des classes! Mais dans VS2017 je reçois toujours le message d'erreur que VS ne peut pas créer un test unitaire pour de telles classes. Je dois en créer un manuellement.
    • C'est une mauvaise réponse, de mon point de vue. Interne devraient être rester, ce n'est pas avoir un drapeau qui leur permettent d'être interne en fonction de l'appelant.
    • Essayer de comprendre ce qui, dans InternalsVisibleTo paramètre à la place de "MyTests". Mon projet de test est appelé api.IntegrationTests. Serait-il [assembly: InternalsVisibleTo("api.IntegrationTests")] ??
    • Le nom de l'assembly qui contient les tests.

    InformationsquelleAutor EricSchaefer
  2. 115

    Si vous voulez tester les méthodes privées, ont un oeil à PrivateObject et PrivateType dans le Microsoft.VisualStudio.TestTools.UnitTesting espace de noms. Ils offrent facile à utiliser wrappers autour de la réflexion nécessaire de code.

    Docs:
    PrivateType, PrivateObject

    Pour VS2017 & 2019, vous les trouverez en téléchargement le MSTest.TestFramework nuget

    • Lorsque le bas de vote, veuillez laisser un commentaire. Merci.
    • C'est stupide de vote en bas de cette réponse. Il pointe vers une solution nouvelle et une très bonne pas mentionné avant.
    • Apparemment, il y a un problème w/ à l'aide de la TestFramework pour l'application de ciblage .net2.0 ou plus récent: github.com/Microsoft/testfx/issues/366
    InformationsquelleAutor Brian Rasmussen
  3. 10

    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.

    InformationsquelleAutor Steven Behnke
  4. 10

    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.

    • Si la méthode est interne n', cela n'empêche pas son utilisation, de l'examen de l'assemblée?
    • Pas à l'aide de InternalsVisibleTo.
    • J'ai parfois l'utilisation de la ForTest approche, mais je trouve qu'il est toujours morte laid (ajout de code qui ne fournit pas la valeur réelle en termes de production de la logique métier). D'habitude je trouve, j'ai eu à utiliser l'approche parce que la conception est somwhat malheureux (c'est à dire d'avoir à le réinitialiser singleton instances entre les tests)
    • Tenté de downvote ce - quelle est la différence entre ce hack et tout simplement faire de la classe interne au lieu de privé? Eh bien, au moins avec compilation conditionnelles. Ensuite, ça devient vraiment pénible.
    • Entendez-vous faire de la méthode interne plutôt que privé? La différence est qu'il est évident que vous avez vraiment voulez qu'il soit privé. Tout le code dans votre production à base de code qui appelle une méthode avec ForTest est évidemment de mal, alors que si vous venez de faire la méthode interne, on dirait que c'est bien d'utiliser.
    • Merci, je le conçois, mais j'ai été préoccupé par la méthode elle-même est maintenant accessible à partir d'un champ d'application plus large. Acquis que la portée est "interne" de sorte qu'il est encore à l'abri du regard indiscret d'un public non averti, donc pas downvote (mon hypothèse était au large de la marque un peu là). J'ai vu une réponse ailleurs que recommandé d'utiliser des classes partielles si l'on faisait l'habitude de cette méthode. Merci encore pour avoir pris le temps de répondre. 🙂
    • Classes partielles ne serait pas faire une différence ici. Ce qui serait bien serait un attribut d'un outil d'analyse statique pourrait utiliser pour vérifier qu'il n'a pas été utilisé à partir de la non-montages d'essai.
    • La seule raison d'utiliser des classes partielles dans ce cas serait de cacher le désordre et l'exclure à partir d'une version de construire.
    • Vous pouvez exclure des méthodes individuelles à l'intérieur d'un communiqué de créer tout aussi facilement dans le même fichier que l'utilisation des classes partielles, de l'OMI. Et si vous ne ce faire, il suggère que vous n'êtes pas à l'exécution de vos tests à l'encontre de votre communiqué de construire, ce qui sonne comme une mauvaise idée de moi.

    InformationsquelleAutor Jon Skeet
  5. 5

    Ajoutant à Eric de réponse, vous pouvez également configurer ce dans le csproj fichier:

    <ItemGroup>
    <AssemblyAttribute Include="System.Runtime.CompilerServices.InternalsVisibleTo">
      <_Parameter1>MyTests</_Parameter1>
    </AssemblyAttribute>
</ItemGroup>

    Ou si vous avez un projet de test par projet pour avoir testé, vous pourriez faire quelque chose comme ceci dans votre Directory.Build.props fichier:

    <ItemGroup>
    <AssemblyAttribute Include="System.Runtime.CompilerServices.InternalsVisibleTo">
      <_Parameter1>$(MSBuildProjectName).Test</_Parameter1>
    </AssemblyAttribute>
</ItemGroup>

    Voir: https://stackoverflow.com/a/49978185/1678053

    InformationsquelleAutor gldraphael