Comment puis-je autoriser l'assemblage (en testant l'unité) à accéder aux propriétés internes d'un autre assemblage?

Question

Je voudrais que mon assemblage de base n'expose pas une certaine classe et j'aimerais quand même pouvoir le tester. Comment puis je faire ça ?

Answer 1

InternalsVisiblePour attribuer à la rescousse!

Il suffit d'ajouter:

 [assembly:InternalsVisibleToAttribute("UnitTestAssemblyName")]
 

à votre fichier AssemblyInfo.cs des classes de base

Voir Assemblées d'amis (Guide de programmation C #) pour connaître les meilleures pratiques.

Answer 2

Avec InternalsVisible si vos assemblées sont fortement nommé, vous devez spécifier la clé publique (remarque: la clé complète pas le jeton de clé publique) par exemple...

[assembly: System.Runtime.CompilerServices.InternalsVisibleTo("BoardEx_BusinessObjects.Tests, 
  PublicKey=0024000004800000940000000602000000240000525341310004000001000100fb3a2d8 etc etc")]

et le tour suivant, c'est vraiment utile pour l'obtention de la clé publique sans recourir à la ligne de cmd...

http://www.andrewconnell.com/blog/archive/2006/09/15/4587.aspx

Answer 3

J'ai mis mes tests d'unité dans la même assemblée que le code de test. Cela fait sens pour moi, parce que je pense à "testez-vous" comme une caractéristique d'une classe, avec des choses comme "initialiser le vous-même" et "décris-toi".

J'ai entendu quelques objections à cette approche, mais peu d'entre eux ont été convaincants.

Il affecte les performances Bah, je dis! Ne pas optimiser l'absence de données brutes! Peut-être, si vous planifiez vos assemblées être téléchargés sur des liaisons lentes, puis en minimisant l'assemblée taille serait la peine.

C'est un risque pour la sécurité. Seulement si vous avez les secrets de vos tests. Ne pas le faire.

Maintenant, votre situation est différente de la mienne, peut-être que ça va faire sens pour vous, et peut-être il ne sera pas. Vous devrez comprendre que vous-même.

Aparté: En C#, une fois, j'ai essayé de mettre mes tests d'unité dans une classe nommée "Tests" qui a été imbriquée à l'intérieur de la classe qu'il a été l'essai. Cela fait de la bonne organisation des choses évidentes. Il permettait également d'éviter la duplication des noms qui se produit lorsque les tests de la classe "Foo" sont dans une classe appelée "FooTests". Cependant, les tests unitaires des cadres que j'avais accès à refusé d'accepter des tests qui n'étaient pas marqués "public". Cela signifie que la classe que vous effectuez le test ne peut pas être "privé". Je ne peux pas penser à une bonne raison d'exiger des tests pour être "public", puisque personne ne les appelle que des méthodes publiques - tout est à travers la réflexion. Si jamais vous écrire un framework de test unitaire .Net, veuillez envisager de permettre à la non-public des tests, pour mon amour!

Answer 4

Je vous conseillerais de ne pas vous lancer dans de tels problèmes ... si vous voulez vraiment tester vos classes "internes", cachez-les simplement dans un espace de noms que seul votre code interne finirait par utiliser. À moins d'écrire un framework à l'échelle du framework .NET, vous n'avez pas vraiment besoin de ce niveau de dissimulation.

Answer 5

Vous pouvez utiliser la réflexion (comme le font les éléments de test MS) ou déclarer l'assembly de test unitaire comme un ami de l'assemblage principal.

L'autre option consiste à placer les tests unitaires dans le même assemblage.