使代码内部化，但可用于其他项目的单元测试

我们将所有单元测试放在他们自己的项目中。我们发现，对于单元测试，我们必须将某些类公开而不是内部类。无论如何要避免这样做。通过公开类而不是密封类，对内存有什么影响？

如果使用的是.NET，则InternalsVisibleTo程序集属性允许您创建“朋友”程序集。这些是特定的强命名程序集，允许它们访问内部类和另一个程序集的成员。

注意，应谨慎使用它，因为它会紧密耦合所涉及的程序集。InternalsVisibleTo的常见用法是用于单元测试项目。由于上述原因，它可能不是在实际应用程序集中使用的好选择。

例：

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

如果它是内部类，则不能孤立地使用它。因此，除了测试内部使用该对象的其他类之外，您实际上不应该对其进行测试。

就像您不应该测试类的私有成员一样，您也不应该测试DLL的内部类。这些类是一些公共可访问类的实现细节，因此应通过其他单元测试很好地进行练习。

这个想法是您只想测试一个类的行为，因为如果您测试内部实现的细节，那么您的测试将很脆弱。您应该能够在不破坏所有测试的情况下更改任何类的实现细节。

如果发现确实需要测试该类，那么您可能首先要重新检查该类是内部类的原因。

出于文档目的

或者，您可以使用Type.GetType方法实例化内部类

例

//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*/ });

对于通用类型，有以下不同的过程：

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*/});

类可以是公开的也可以是密封的。

但是，不要那样做。

您可以创建一个工具来反映内部类，并发出一个通过反射访问所有内容的新类。MSTest做到了。

编辑：我的意思是，如果您不想在原始程序集中包含-any-测试内容；如果成员是私人的，这也适用。