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

Nous mettons tous nos tests unitaires dans leurs propres projets. Nous constatons que nous devons rendre certaines classes publiques au lieu d'interne juste pour les tests unitaires. Y a-t-il de toute façon pour éviter d'avoir à faire cela. Quelle est l'implication de la mémoire en rendant les classes publiques au lieu de scellées?

Si vous utilisez .NET, l' attribut d'assembly InternalsVisibleTo vous permet de créer des assemblys "amis". Il s'agit d'assemblys spécifiques fortement nommés qui sont autorisés à accéder aux classes internes et aux membres de l'autre assembly.

Notez que cela doit être utilisé avec discrétion car il couple étroitement les assemblys impliqués. Une utilisation courante d'InternalsVisibleTo est pour les projets de test unitaire. Ce n'est probablement pas un bon choix pour une utilisation dans vos assemblys d'application réels, pour la raison indiquée ci-dessus.

Exemple:

[assembly: InternalsVisibleTo("NameAssemblyYouWantToPermitAccess")]
namespace NameOfYourNameSpace
{

S'il s'agit d'une classe interne, elle ne doit pas être utilisée de manière isolée. Par conséquent, vous ne devriez pas vraiment le tester en dehors du test d'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 d'implémentation d'une classe accessible au public, et doivent donc être bien utilisées à travers d'autres tests unitaires.

L'idée est que vous ne voulez tester que le comportement d'une classe car si vous testez les détails de l'implémentation interne, vos tests seront fragiles. Vous devriez pouvoir modifier les détails d'implémentation de n'importe quelle classe sans interrompre tous vos tests.

Si vous trouvez que vous avez vraiment besoin de tester cette classe, vous voudrez peut-être réexaminer pourquoi cette classe est interne en premier lieu.

à des fins de documentation

vous pouvez également instancier une classe interne en utilisant la Type.GetTypemé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*/});

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

Mais ne fais pas ça.

Vous pouvez créer un outil pour réfléchir sur les classes internes et émettre une nouvelle classe qui accède à tout via la réflexion. MSTest fait cela.

Edit: Je veux dire, si vous ne voulez pas inclure -any- des éléments de test dans votre assemblage d'origine; cela fonctionne également si les membres sont privés.