Rendre le code interne mais disponible pour les tests unitaires d'autres projets

Question

Nous mettons tous nos tests unitaires dans leurs propres projets. Nous trouvons que nous devons rendre certaines classes publiques au lieu d'internes juste pour les tests unitaires. Est-il de toute façon pour éviter d'avoir à faire cela. Quelles sont les implications de la mémoire en rendant les classes publiques au lieu d'être scellées?

Answer 1

Si vous utilisez .NET, l'attribut d'assemblage InternalsVisibleTo vous permet de créer des assemblages "amis". Ce sont des assemblys spécifiques fortement nommés qui sont autorisés à accéder aux classes internes et aux membres de l'autre assembly. Notez que ceci doit être utilisé avec discrétion car il couple étroitement les assemblages impliqués. Une utilisation courante pour InternalsVisibleTo est pour les projets de tests unitaires. Ce n'est probablement pas un bon choix à utiliser dans vos assemblages d'applications réels, pour la raison indiquée ci-dessus.

Answer 2

Les classes peuvent être à la fois publiques et scellées.

Mais, ne faites pas cela.

Vous pouvez créer un outil pour réfléchir sur des classes internes et émettre une nouvelle classe qui accède à tout via la réflexion. MSTest le fait. Editer: Je veux dire, si vous ne voulez pas inclure de matériel de test dans votre assemblage d'origine; Cela fonctionne également si les membres sont privés.

Answer 3

S'il s'agit d'une classe interne, il ne doit pas être utilisé de manière isolée. Par conséquent, vous ne devriez pas vraiment le tester en dehors de tester une autre classe qui utilise cet objet en interne.

Tout comme vous ne devriez pas tester les membres privés d'une classe, vous ne devriez pas tester les classes internes d'une DLL. Ces classes sont des détails de mise en œuvre de certaines classes accessibles au public, et devraient donc être bien exercées à travers d'autres tests unitaires. L'idée est que vous ne voulez tester le comportement d'une classe que parce que si vous testez des détails d'implémentation internes, vos tests seront fragiles. Vous devriez être capable de changer les détails d'implémentation de n'importe quelle classe sans casser tous vos tests.

Si vous trouvez que vous avez vraiment besoin de tester cette classe, vous pouvez réexaminer pourquoi cette classe est interne en premier lieu.

Answer 4

à des fins de documentation

Sinon, vous pouvez instancier classe interne en utilisant Type.GetType méthode

exemple

//IServiceWrapper is public class which is 
//the same assembly with the internal class 
var asm = typeof(IServiceWrapper).Assembly; 
//Namespace.ServiceWrapper is internal 
var type = asm.GetType("Namespace.ServiceWrapper"); 
return (IServiceWrapper<T>)Activator 
    .CreateInstance(type, new object[1] { /*constructor parameter*/ }); 

pour le type générique il existe différents processus comme ci-dessous:

var asm = typeof(IServiceWrapper).Assembly; 
//note the name Namespace.ServiceWrapper`1 
//this is for calling Namespace.ServiceWrapper<> 
var type = asm.GetType("Namespace.ServiceWrapper`1"); 
var genType = type.MakeGenericType(new Type[1] { typeof(T) }); 
return (IServiceWrapper<T>)Activator 
    .CreateInstance(genType, new object[1] { /*constructor parameter*/});